mazzy iscrafmпо моему скромному мнению, следует различать непосредстенно список и навигатор для этого списка.
Ок. Поговорим об этом?

Могут ли быть многоуровневые списки?

Несомненно.

mazzy
Могут ли быть многоуровневые навигаторы?

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

mazzy
Если начать говорить о реализации, то каков способ лучше - хранить группы и элементы в одной таблице (самоссылки) или хранить в разных таблицах. Сколько должно быть таблиц для отображения дерева с заданным уровнем (например, сколько таблиц для дерева с 5 уровнями вложенности).


Мне кажется, группы нужно хранить отдельно. Поскольку чаще всего группы и элементы - суть разные сущности с разными признаками, и смешивать их в одной таблице не очень правильно. Таким образом получается, что справочник элементов - плоский, а групп - иерархический с самоссылками. Т.е. для дерева с 5 уровнями вложенности нужно 2 таблицы. Интересно послушать иные мнения на этот счет.

mazzy
Должен ли пользователь выбирать сначала первую группу, затем вторую, третью и так далее, чтобы добраться до нужного ему элемента?
Т.е. должен ли пользователь делать выбор именно в этом предопределенном порядке?

Могу предложить такой вариант:
В дереве должен присутствовать узел "Все элементы". При выборе элемента дерева показываются все элементы, относящиеся к этому узлу и всем его подузлам. При необходимости, можно завести переключатель "Показывать элементы для дочерних узлов" - когда он отключен, видим только элементы выбранного узла (но не подузлов). Фильтры по прочим признакам элементов (отличным от признака "группа") работают в контексте выбранного узла. Соответственно, если выбран узел "все элементы" фильры работают глобально.