Недавно на форуме один посетитель задал простой вопрос, который превратился в очень интересную дискуссию.

Возможно ли в запросе CAML сделать так, чтобы выбирались только элементы с 10 по 20 к примеру? Это необходимо для организации пейджинга блога.

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

Когда топикстартеру задали вопрос зачем же все-таки так делать он ответил:

так задачу поставили( надо видеть количество страниц и переходы на них...

А дальше еще интереснее:

Руководство сказало "надо", мы сказали "есть!"))

Как ни парадоксально, но тем кто лучше всех должен разбираться в решениях на некоторой платформе совершенно все равно насколько полезны и эффективны их решения. Собственно само решение диктуется людьми (в данном случае “руководством”, иногда бывают аналитики или менеджеры), которые заведомо хуже в этом разбираются.

Самые простые задачи, типа сделать  номера страниц и выводить их количество, стоят наиболее внимательного рассмотрения. Ведь если бы это было элементарно, то уже давно было бы сделано и расписано в каждой книге. Но такого не наблюдается и этому есть причины. Но надо в первую очередь не ковыряться в причинах почему что-то нельзя сделать в SharePoint, а пытаться понять что же надо сделать чтобы удовлетворить потребности пользователей\бизнеса.

Для начала стоит заметить что в SharePoint есть шаблон сайта блога. Ему конечно далеко до профессиональных блогодвижков, но в некотором роде задачи свои решает и неплохо кастомизируется.

Но тут кому-то пришло в голову что там не хватает номеров страниц и перехода по ним. Попробуем разобраться откуда такая мысль.

Вариант первый

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

Скорее всего, именно из-за этих фич используется SharePoint, а не опенсорсная CMS. Но наличие таких фич  приводит к невозможности перехода к конкретной странице и подсчету их количества.

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

Создание такой системы – медвежья услуга.  Стандартные возможности SharePoint протестированы, документированы и работают. Создавая свое, похожее но другое, вы не можете вложить столько же сил в тестирование и документирование, сколько вложил Microsoft. Скорее всего решение будет работать гораздо хуже стандартного. Кроме того созданное решение надо поддерживать, апгрейдить итд.

Совокупная стоимость владения повышается, а эффект очень локален. Ведь новая система более привычна узкому кругу лиц.  Гораздо более правильное решение в данном случае – обучить пользоваться возможностями SharePoint.

Вариант второй

Возможно людям действительно надо переходить на несколько страниц вперед. Стоит понять почему такое происходит. Скорее всего то что нужно не находится на первой странице.

В этом случае правильное решение – настроить представления и\или поиск таким образом чтобы нужная информация была на первой странице.

Вариант третий

Кнопочки с номерами страниц – элемент визуального дизайна портала. Такое часто случается когда дизайн создается без оглядки на возможности SharePoint. То есть изначально полезности  в этом элементе нет, есть только визуальная “изюминка”.

В этом случае можно придумать другую “изюминку”. Например сделать unlimited scroll на странице списка. Такой элемент гораздо более удобен для пользователя, но при этом не требует подсчета количества страниц.

Заключение

Процесс создания решения это не написание кода. Особенно в среде SharePoint, где много стандартных возможностей, стоит набольшее внимание уделять пониманию решаемых проблем и поиску консенсуса (не компромисса).

PS. Этот вопрос подробно описан в книге Брукса Design of Design. Рекомендую всем к прочтению.

Теги : SharePoint