Можно ли верить разработчикам?

[Alks]

Цитата:

Изначально опубликовано Maxim Gorbunov
А в UtilIdElements ParentId для иерархии, вообще говоря, и не используется. ParentId ненулевой только для определенного набора объектов и он, вообще, не соответствует тому дереву, которое Вы видите в качестве AOT.

А как же древовидность проектов? Древовидность форм, кнопок, панелей в AOT? Древовидность датасоурсов в запросах? И т.д. и т.п. Или это и есть тот "определенный набор объектов" про который вы говорите?

Цитата:

В принципе, это же и ответ на второй вопрос. Кто Вам мешает сделать интерфейс пользователя в виде дерева?

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

Цитата:

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

По моему mazzy говорил где то мысль примерно следующего содержания: "не решайте за пользователя что ему будет удобно, а что - нет.".

Цитата:

И совершенно не обязательно для этого выстраивать много уровней иерархии.
Опять же, посмотрите на AOT.

Вы находите ситуацию когда перед вами выпадает список из 3500 классов, или 1500 таблиц удобной? Вы находите ситуацию когда перед именем каждого класса / таблицы / menuitem-а приходится ставить префикс модуля иначе он потеряется в общем списке нормальной? Когда найти нужный объект в списках из тысяч элементов представляется возможным только набирая его имя на клавиатуре / т.е. по сути надо знать наперед как он называется. Когда приемлемым решением по отделению мух от котлет являются проекты, в которым, кстати, соблюдена произвольная древовидность.

Цитата:

P.S.: При грамотном построении системы кодировки объектов можно и по частям поля искать.

Я уже озвучил выше почему это не так, не поленюсь зацитировать, и еще добавлю к тому списку:

1. У такого подхода возможны "ложные" срабатывания
2. Проблему отчётов он не решает, т.к. в X++ в селектах недопустимо в условиях указывать части полей
3. Такой подход не работает пока менеджеры еще не притерлись к классификации, т.к.:
4. В таком подходе невозможно найти что то, не зная правил и кодов классификации (в древовидном подходе - запросто)
5. Когда приходит клиент и вы у него спрашиваете "что вас интересует?", а он по еврейски в ответ задаёт вопрос "а что вы можете предложить?" только древовидный классификатор сможет быстро дать ему ответ на все вопросы.
6. Грамотной назвать систему в которой внутри столбца хранятся значения, которые по правилам нормализации надо выносить в отдельные стобцы нельзя.