Цитата:
Сообщение от
Narayana
Все читал, все смотрел и даже немного думал об этом обо всем...
Похоже, главное слово в этом предложении "немного"
![Smile](/forums/images/smilies/smile.gif)
Подумает еще, пожалуйста
Цитата:
Сообщение от
Narayana
Мне кажется, вы не признаете очевидного. А именно того, что правильно составленная иерархия номенклатур, тому человеку, который ее составил, позволяет сравнительно легко ориентироваться в списке номенклатур.
Ключевое фраза в этом предложении "
тому человеку, который ее составил". Это один из аргументов "против" в статье
mazzy. И в статье он объясняет "почему". Перечитайте этот момент, пожалуйста.
Цитата:
Сообщение от
Narayana
Думаю, что вы при этом забываете про потребность не только найти номенклатуру, про которую знаете, что она есть, но и просто посмотреть, что есть в разных уровнях иерархии.
Во-первых, наложить фильтр на линейный список значительно проще (в смысле, чтобы посмотреть, что есть в группе). А во-вторых, попробуйте ответить на вопрос "зачем?". Т.е. с какой целью, и главное,
как часто, у Вас возникает подобная необходимость. Это
основная задача пользователей?
Цитата:
Сообщение от
Narayana
Спорить о вкусах здесь сложно.
Дело вовсе не во вкусах, а в практических проблемах, возникающих при использовании дерева. Задумайтесь о том, какие операции
чаще всего выполняет пользователь со справочником. А потом прикиньте, как эти самые
часто выполняемые операции изменятся (упростятся или усложняться) при
обязательном (!) использовании дерева.
Цитата:
Сообщение от
Narayana
Ну, хорошо, вам сложно полистать узлы TreeView, чтобы понять, по какому принципу сортируется товар, а каким образом вы, не будучи программистом, будете исследовать вопрос о том, по каким полям в связанных таблицах вы можете фильтровать записи в основной таблице??
А зачем мне это знать, если я не программист? В каких местах (формах)
пользовательского интерфейса возникает подобная необходимость? И какое отношение к этому вопросу имеет TreeView?
Цитата:
Сообщение от
Narayana
Почему-то вопрос о связанных таблицах с дополнительными атрибутами все время стыдливо опускается, но ведь это и есть самое сложное место.
При этом при построении фильтра над целой гроздью таблиц, в поиск можно включить значения полей только непосредственно связанных между собой таблиц, а вот через одну уже нельзя. Ну и где в этом месте ваша хваленая фильтрация?
И каким образом в этой задаче может помочь TreeView?
Цитата:
Сообщение от
Narayana
В общем не так все просто, чтобы надувать щеки только в сторону одного варианта.
Угу. Странно только, что Вы не применяете это правило к себе. Вы ведь не пытаетесь сравнить. Для Вас существует только один вариант
Цитата:
Сообщение от
Narayana
TreeView был и будет занимать одно из самых важных и сложных мест интуитивного пользовательского интерфейса, хотите вы этого или нет.
Вы забыли уточнить, для каких именно задач. Никто ведь не отрицает удобство использования TreeView в
определенных областях. Но пытаться "воткнуть" TreeView везде и всегда крайне порочная практика. К сожалению, многим требуются "шашечки", а не "ехать"
Цитата:
Сообщение от
Narayana
Просто потому, что это пользователю понятно, а форма построения сложного фильтра, которая просто воспроизводит SQL запрос, - не понятна большинству.
Интересный вывод.
![Smile](/forums/images/smilies/smile.gif)
Вы уверены, что читали статью
mazzy? Перечитайте ее еще раз, пожалуйста. В данном случае о том, как именно (по каким критериям) фильтрует записи TreeView и что делать, если Вам надо задать другой критерий фильтрации. Не тот по которому построено TreeView.