Рабочее обсуждение ТЗ

Участники

• Евгений Колесников
• Александр Колесников

Предварительный вариант решения

Иерархия

• Необходимо обеспечить иерархию контента. Здесь возникает вопрос с обеспечением уникальности имен, т.к. на разных уровнях имена экземпляров контента могут совпадать. Для решения этой проблемы, как вариант, возможно задание составного имени экземпляра контента - "имя parent-контента+имя текущего контента", при этом в качестве разделителя может выступать как какой-либо спец.символ, так и можно вообще без спецсимволов, а "отрезаемую" часть определять через свойство parent у документа.

• Отдельный вопросом, но связанным с предыдущим является проблема указания порядка страниц в том случае когда они находятся на одном уровне. Для обеспечения этого возможно:
  • создание нового класса со свойством "вес", где будет указываться цифровой вес документа (а потом все документы на одном уровне иерархии сортироваться по этому весу). Подключение доп. класса к основному классу страницы может происходить аналогично тому как реализовано подключение доп. класса tag.
  • Возможно также следует реализовать вообще отдельный класс, где свойствами будет не только вес, но и parent - и в этом случае не использовать parent-свойства у стандартного класса страниц вики.
  • присвоение цифровых имен экземплярам контента (страницам), так чтобы они показывали и иерархию и вес документа одновременно. В этом случае внутренее имя документа (также отображаемое в адресной строке браузера) будет что-то вроде 020414, где - 02 - 1-ый уровень и вес в 1-ом уровне иерархии, 04 - 2-ой уровень и вес в 2-ом уровне иерархии и т.д.

• Вообще, следует иметь ввиду, что вопросы уникальности имени, иерархии и веса документа (т.е. сортировки в пределах уровня) - это разные вопросы и возможно их вообще не следует смещивать (как они смешиваются в большинстве вышеуказанных вариантов) а решать обсолютно раздельно, а именно: а) parent задается стандартными средствами xwiki и здесь не требуется ничего реализовывать б) вес документа реализовывать через отдельный класс, аналогичный классу тэгов, который "привязывается" к основному документу в) уникальность внутренних имен документов обеспечивать тем, что в качестве имени указывать, например, id документа (xwiki обеспечивает уникальное id документа стандартными средствами).

• Должна быть сделана панель, отображающая иерархию документа, в зависимости от parent и веса документа. Также эта иерархия может отображаться на верхних уровнях контента (начало иерархий).

Категории

• Необходимо реализовать категории, аналогично тому, как реализованы категории в блогах. Существует несколько вариантов реализации:
  • Единый класс категорий (только называется как-то по другому, чтобы не пересекаться с классом категорий из блогов). В этом случае в рамках единой структуры категорий указываются и Участки и Предприятия. 
  • 2 разных класса для предприятий и участков, но работающих почти идентично. Это может иметь больший смысл чем единый класс, так как к предприятиям и участкам преъявляются чуть-чуть разные требования: участки всегда выбираются и показываются строго по одному. Предприятия же могут выбираться по несколько сразу (т.к. страница с документацией может относиться сразу к нескольким предприятиям). Мало того, именно для предприятий существует отдельное "предприятие" - general, страницы помеченные таким образом должны показываться и для всех других выбранных предприятий (т.е. если я выбрал Moldtelecom, мне показываются все страницы, у которых установлена категория General + все страницы у которых установлена категория Moldtelecom). Для участков, несмотря на то, что там также есть General - такого нет. Всегда показывается только контент выбранного участка.
  • Реализовать через категории только предприятия, а участки (так как они фактически совпадают с началом иерархий) - реализовать через spaces. При этом варианте визуально отображать участки в виде горизонтального меню закладок по аналогии того как это сделано в ColibriNavigationHeaderModApplication.

• Варианты визуализации для категорий сильно зависят от выбранной схемы реализации, однако самое главное - чтобы категории как-бы были дополнительным фильтром для иерархической панели контента. А сами варианты могут быть следующими:
  • Если для предприятий и участков единый класс - то единая панелька, фильтрующая панельку с иерархией. Для предприятий при этом следует обеспечивать возможность установки "галок" - множественный выбор, а галка "General" для предприятий вообще всегда должна быть выбрана. Правда в этом случае не понятно, как обеспечить, чтобы в участках были не галки, а optionbuttons ...
  • Если 2 разных класса для предприятий и участков - тогда проще 2 разных панели, каждая из которых является фильтрующей для основной панели иерархии. В предприятиях множественный выбор с галками, в участках - только переключение между участками.
  • Если же использовать ColibriNavigationHeaderModApplication - то предприятия отображаются как панелька слева (с галками) а участки - в горизональном меню вверху.

Прочее

• Фактически нет необходимости реализовывать собственный класс для экземпляров контента как в блогах. Достаточно будет реализовать дополнительные классы к стандартному классу страниц xwiki, аналогично тому, как реализован класс тэгов для всех стандартных страниц XWiki.

• Тэги (как стандартное средство) тоже будут использоваться для задания таких вещей как сисфид документа, автор и пр.

• Имеются определенные проблемы с многоязычностью при использовании собственных классов для контента. Следует провентилировать этот вопрос. См. подробнее тут http://jira.xwiki.org/jira/browse/XWIKI-69. По ссылке предлагается решение, а еще можно попробовать параметризацию класса.