Разработка и тестирование решений SharePoint с использованием API на компьютере, на котором не установлен SharePoint.

Поиск.

Простите за тираду, но ...

Всякий раз, когда я пытаюсь использовать функцию поиска Sharepoint (как конечный пользователь, я не разработчик Sharepoint), мне кажется, что я получаю самый запоздалый список бесполезных результатов. Я либо ничего не получаю, когда точно знаю, что есть документы, содержащие то, что я ищу, либо получаю огромный список бесполезного шума.

Затем я теряюсь в запутанном лабиринте сайтов, коллекций и списков; но я понятия не имею, в чем разница между всеми этими вещами и почему иногда, когда я нахожусь в одном, я не могу сразу вернуться к другому. Или что-то.

Заставляет меня чувствовать себя бестолковым идиотом, в чем, я полагаю, я так далеко, как и Sharepoint.

• Хранение документа в нескольких библиотеках документов
• Расширенная версия веб-части запроса контента, которая имеет те же функции, что и обычная веб-часть списка (например, представления, фильтры, сортировка, простой в использовании интерфейс)

Я согласен с еще одним ответом, что разработку в несерверной среде должно быть проще.

Кроме того, это может сделать с улучшенной готовой поддержкой стандартов доступности.

Развертывание контента

Он был улучшен во всех выпусках Post-SP1, но вы не можете легко развернуть контент в Sharepoint. Это всегда рискованно.

Существует инструмент, разработанный с Крис О'Брайен под названием SPContentDeployment, который использует API развертывания контента, но он по-прежнему является сторонним. Это должно быть реализовано в Sharepoint.

легкость развития

хорошо, если они дадут больше свободы разработчику, чтобы он мог делать то, что им нужно, так, как им нравится, это будет здорово

то, как это происходит сейчас, просто замедляет мою повседневную работу, но мне все равно нужно работать над этим, потому что более крупные парни думают, что это лучшее, что есть на свете

Было бы неплохо оптимизировать SharePoint для работы с огромными библиотеками документов. Где-то порядка 10 миллионов плюс было бы неплохо. Я знаю, что работаю с патологическим случаем, но производительность очень быстро падает, когда вы получаете более 100 тысяч записей в библиотеке.

Агрегатор, работающий с семействами сайтов и веб-приложениями.

Запуск рабочих процессов на уровне списка или сайта, а не только на уровне элемента. (хотел бы это)

нативные веб-части Silverlight и лучшая производительность ...

Я думаю, что SharePoint должен быть XHTML-совместимым из коробки. Тот факт, что это не так, довольно смехотворен. Не говоря уже о том, что есть по крайней мере один элемент управления, который выводит недопустимый HTML (отсутствует закрывающий тег в SummaryLinks)!

Мои пожелания к Sharepoint [платформе] не отличаются от пожеланий к любым другим программным продуктам.

Они должны быть четко и легко предсказуемыми, понятными, поддерживаемыми, управляемыми, способными интегрировать и решать запросы клиентов.

Например, Sharepoint часто объясняется, позиционируется, разбавляется, смешивается и путается с MS в качестве портальных решений, хотя такая характеристика недоступна, потому что для этих целей существуют другие (и более специфические) продукты MS, но Sharepoint лучше охарактеризовать как поддержку совместной работы. Платформа.

Он должен быть обратно совместимым и честным с клиентами. Как следует понимать требования к оборудованию в «64-битном, четырехъядерном» для SharePoint Server 2010 [1], если он действительно устанавливается и работает без проблем на компьютерах с 32-битными одноядерными процессорами?
Какой смысл в этой измене?

[1]
Требования к оборудованию и программному обеспечению (SharePoint Server 2010)
http://technet.microsoft.com/en-us/library/cc262485.aspx#section2

Возможность перетаскивать электронные письма и вложения прямо из папки «Входящие» в библиотеку документов (подключенную к Outlook), не выходя из клиента Outlook.