Skip to Content
Last modified by Opinca Mihail on 2010/03/07 13:49
Show last authors
1 === Участники ===
2
3 * Евгений Колесников
4 * Александр Колесников
5
6 === Предварительный вариант решения ===
7
8 ===== Иерархия =====
9
10 * Необходимо обеспечить иерархию контента. Здесь возникает вопрос с обеспечением уникальности имен, т.к. на разных уровнях имена экземпляров контента могут совпадать. Для решения этой проблемы, как вариант, возможно задание составного имени экземпляра контента - "имя parent-контента+имя текущего контента", при этом в качестве разделителя может выступать как какой-либо спец.символ, так и можно вообще без спецсимволов, а "отрезаемую" часть определять через свойство parent у документа.
11
12 * Отдельный вопросом, но связанным с предыдущим является проблема указания порядка страниц в том случае когда они находятся на одном уровне. Для обеспечения этого возможно:
13 ** создание нового класса со свойством "вес", где будет указываться цифровой вес документа (а потом все документы на одном уровне иерархии сортироваться по этому весу). Подключение доп. класса к основному классу страницы может происходить аналогично тому как реализовано подключение доп. класса tag.
14 ** Возможно также следует реализовать вообще отдельный класс, где свойствами будет не только вес, но и parent - и в этом случае не использовать parent-свойства у стандартного класса страниц вики.
15 ** присвоение цифровых имен экземплярам контента (страницам), так чтобы они показывали и иерархию и вес документа одновременно. В этом случае внутренее имя документа (также отображаемое в адресной строке браузера) будет что-то вроде 020414, где - 02 - 1-ый уровень и вес в 1-ом уровне иерархии, 04 - 2-ой уровень и вес в 2-ом уровне иерархии и т.д.
16
17 * Вообще, следует иметь ввиду, что вопросы уникальности имени, иерархии и веса документа (т.е. сортировки в пределах уровня) - это разные вопросы и возможно их вообще не следует смещивать (как они смешиваются в большинстве вышеуказанных вариантов) а решать обсолютно раздельно, а именно: а) parent задается стандартными средствами xwiki и здесь не требуется ничего реализовывать б) вес документа реализовывать через отдельный класс, аналогичный классу тэгов, который "привязывается" к основному документу в) уникальность внутренних имен документов обеспечивать тем, что в качестве имени указывать, например, id документа (xwiki обеспечивает уникальное id документа стандартными средствами).
18
19 * Должна быть сделана панель, отображающая иерархию документа, в зависимости от parent и веса документа. Также эта иерархия может отображаться на верхних уровнях контента (начало иерархий).
20
21 ===== Категории =====
22
23 * Необходимо реализовать категории, аналогично тому, как реализованы категории в блогах. Существует несколько вариантов реализации:
24 ** Единый класс категорий (только называется как-то по другому, чтобы не пересекаться с классом категорий из блогов). В этом случае в рамках единой структуры категорий указываются и Участки и Предприятия.
25 ** 2 разных класса для предприятий и участков, но работающих почти идентично. Это может иметь больший смысл чем единый класс, так как к предприятиям и участкам преъявляются чуть-чуть разные требования: участки всегда выбираются и показываются строго по одному. Предприятия же могут выбираться по несколько сразу (т.к. страница с документацией может относиться сразу к нескольким предприятиям). Мало того, именно для предприятий существует отдельное "предприятие" - general, страницы помеченные таким образом должны показываться и для всех других выбранных предприятий (т.е. если я выбрал Moldtelecom, мне показываются все страницы, у которых установлена категория General + все страницы у которых установлена категория Moldtelecom). Для участков, несмотря на то, что там также есть General - такого нет. Всегда показывается только контент выбранного участка.
26 ** Реализовать через категории только предприятия, а участки (так как они фактически совпадают с началом иерархий) - реализовать через spaces. При этом варианте визуально отображать участки в виде горизонтального меню закладок по аналогии того как это сделано в [[ColibriNavigationHeaderModApplication>>http://code.xwiki.org/xwiki/bin/view/Applications/ColibriNavigationHeaderModApplication]].
27
28 * Варианты визуализации для категорий сильно зависят от выбранной схемы реализации, однако самое главное - чтобы категории как-бы были дополнительным фильтром для иерархической панели контента. А сами варианты могут быть следующими:
29 ** Если для предприятий и участков единый класс - то единая панелька, фильтрующая панельку с иерархией. Для предприятий при этом следует обеспечивать возможность установки "галок" - множественный выбор, а галка "General" для предприятий вообще всегда должна быть выбрана. Правда в этом случае не понятно, как обеспечить, чтобы в участках были не галки, а optionbuttons ...
30 ** Если 2 разных класса для предприятий и участков - тогда проще 2 разных панели, каждая из которых является фильтрующей для основной панели иерархии. В предприятиях множественный выбор с галками, в участках - только переключение между участками.
31 ** Если же использовать ColibriNavigationHeaderModApplication - то предприятия отображаются как панелька слева (с галками) а участки - в горизональном меню вверху.
32
33 ===== Прочее =====
34
35 * Фактически нет необходимости реализовывать собственный класс для экземпляров контента как в блогах. Достаточно будет реализовать дополнительные классы к стандартному классу страниц xwiki, аналогично тому, как реализован класс тэгов для всех стандартных страниц XWiki.
36
37 * Тэги (как стандартное средство) тоже будут использоваться для задания таких вещей как сисфид документа, автор и пр.
38
39 * Имеются определенные проблемы с многоязычностью при использовании собственных классов для контента. Следует провентилировать этот вопрос. См. подробнее тут http://jira.xwiki.org/jira/browse/XWIKI-69. По ссылке предлагается решение, а еще можно попробовать параметризацию класса.