Вкратце о текущей работе - HTMLayout Spy проект для отладки приложений сделанных на HTMLayout .Для представления пользовательского документа (DOM-tree), потребовалось сделать дерево (как оказалось, стандартное, не подходит для работы с изменяющимися данными и больше служит демонстрационным целям).
Тем не менее, оно есть и работает. Можно добавлять-удалять узлы, делать апдейт и автоматически раскрывать дерево на интересующем элементе.
Самым сложным оказался апдейт дерева. Путаница с индексами, одновременным созданием-удалением детей оказалась настоящим кошмаром. Еще один момент - пожалуй, это первый behavior разработанный с возможностью сделать его обобщенным. Думаю, после мелких доделок (небольшие переработки, создание примеров) выложу его в лаборатории.
12 комментариев:
С одной стороны, любопытно глянуть на результирующий behavior.
С другой - очень мне печально смотреть на то, как пользователи современных UI-библиотек, вместо использования возможностей этих библиотек на полную катушку банально вопроизводят в них "старорежимные" контролы (из которых дерево - самый уродский и дебильный, у него нет в принципе ни одной положительной стороны).
Твоя нелюбовь к деревьям хорошо известна :)
В начале разработки этого behavior ставил такие задачи:
1. Получить "стандартное" работающее дерево (то что сейчас есть/почти есть)
2. Сделать tree-grid. Это насущная проблема для HTMLayout Spy
3. Задача максимум - повторить твои эксперименты с деревьями для файловой системы (pure-css)
В результате хочется получить один хороший behavior с несколькими примерами использования (и различными представлениями).
Пока решил только первую задачку.
В ближайшее время буду решать остальные.
Что касается представления DOM-tree, то как мне кажется банальное стандартное дерево, наиболее подходящее решение.
Если есть альтернативные предложения - буду рад услышать (развернутая аргументация - дополнительный плюс :) )
Любые пожелания или просто мысли об идеальном представлении иерархии тоже приветствуются (тут достаточно схематичной картинки, как должен выглядеть результат). Потому как сейчас банально не хватает времени на эксперименты и детальную проработку темы.
treegrid, кстати, единственный в мире контрол, который хуже tree :)
если последний - это просто неудачный способ отображения вложенности; то первый - принципиальный mis-feature :) хотите об этом поговорить? :)
> Любые пожелания или просто мысли об идеальном представлении иерархии тоже приветствуются (тут достаточно схематичной картинки, как должен выглядеть результат).
Попытался по-быстрому найти какой-нибудь online collaborative drawing tool, чтобы показать, но увы, они все неизбывно чудовищны.
Ладно, попробую словами, если дальше по дискуссии понадобится - будут картинки.
1. в целом, я вообще считаю что сложные контролы надо под каждую задачу отдельно дизайнить (благо htmlayout это вполне позволяет)
2. но, тем не менее, то для чего используются деревья: это отображение одного из двух отношений - либо вложенности (А лежит внутри Б - элементы DOM) либо группировки (несколько Б озаглавлено А - папки с письмами в Outlook). Тогда как стандартное дерево-"лесенка" отображает исключительно несуществующее в природе отношение "лежит правее и ниже".
От этого надо плясать.
В частности, для элементов DOM мне кажется неплохим приближением такая картинка: http://imho.com.ua/images/ascii.txt (извиняюсь за стилистику, но от пейнтбраша тошнит меня).
К этому желательно добавить, чтобы сильно развернутые элементы не в фокусе не уезжали за край экрана, а свертывались, так что в целом, исследуемая структура всегда оказывалась на экране.
Мне кажется, такой стиль представления, занимая ненамного больше места чем стандартное дерево, намного "интуитивно информативнее" (и занимаемое место использует более осмысленно, чем лесенка с огромными пустыми полями слева-вверху и справа-внизу).
1. Tree Grid. Я очень хочу поговорить об этом :)
Практический пример. Требуется компактно задать
a. Свойства DOM-element-а
Handle
Uid
state
Position
__top
__left
__bottom
__right
Num childs: N
Num attributes
__attrib0, value 0
__attrib1, value 1
__attrib2, value 2
(подчеркивание - попытка передать отношение вложенности)
b. Стили DOM-element-а
foreground
__foreground-attachment
__foreground-image
__foreground-position
border ( потенциально отдельно для bottom, left, top, right)
__color
__style
__width
...
И для того и для другого treegrid вполне подходит. Альтернатив я сходу не нашел (впрочем не сильно искал - tree grid в отладчике студии кажется вполне симпатичной штукой).
2. Дерево. Спасибо за идею - очень симпатично!
Безусловно буду пробовать, видимо после первого рилиза (он и так, зараза, затянулся).
Что настораживает по первому впечатлению - если давать имена элементам как type.class#id, то дерево сильно потянется по горизонтали (если попытаться вставлять дополнительную информацию, например, атрибуты, то скорее всего такой контрол перестанет быть "читаемым". Тут уже надо будет вплотную работать с "умными свертываниями" чтобы удалять с экрана несущественную информацию).
Отдельный вопрос - навигация по такому дереву с помощью клавиатуры.
>Тогда как стандартное дерево-"лесенка" отображает исключительно несуществующее в природе отношение "лежит правее и ниже".
Честно говоря, у меня не было проблем с такой трактовкой взаимоотношений родитель-потомок.
Вот как выглядит эта страничка в фаербаге http://htmlayoutlab.com/img/other/blogger-html-tree.png
На мой взгляд, вполне информативно.
(блоггер не позволяет вставлять картинки в дискуссии :( )
В любом случае, буду пробовать эту идею. Большущее спасибо! :)
PS Блоггер еще вдобавок и "лишние" пробелы в комментариях срезает.
PSS Так и не нашел способа отправлять оповещения о комментариях по email всем комментировавшим ранее :\
про tree-grid думаю.
про firebug и его дерево: жуткая мусорка :))
отношение вложенности еще можно передать стандартным изображением groupbox'а: http://imho.com.ua/images/ascii2.txt
мерзость варианта в firebug'е я сполна ощутил при попытке его перерисовать - без линейки не определишь, что куда вложено, как и не ответишь на вопрос "а сколько элементов вложено в этот". мой вариант не только лишен этого недостатка, но еще и компактнее. (хотя первый мне все равно больше нравился)
Про tree-grid: для описываемого случая приемлемо (как проперти-грид с вложенностью, а не как дерево с несколькими колонками), хотя наверное можно что-то симпатичнее изобрести. Неприемлемо - это как в Янусе.
Но если исходить из "проперти-грид с вложенными пропертями", то сотворить этот behavior становится куда проще ;)
Похоже, что да, с деревом придется еще много экспериментировать.
>Но если исходить из "проперти-грид с вложенными пропертями", то сотворить этот behavior становится куда проще ;)
Вариант, мне почему-то в голову не пришел. Спасибо.
>Неприемлемо - это как в Янусе.
А что в Янусе с property-grid-ом не так?
> А что в Янусе с property-grid-ом не так?
В Янусе "не так" - отображение таблицы сообщений treegrid'ом. Удивительной бесполезности изобретение, жутко громоздкое, при этом практически не помогающее отслеживать ход беседы для сколь-нибудь длинных и/или разветвленных дискуссий.
А, понятно, я думал тебе опции не понравились. У них, кстати, тоже не все гладко - одним взглядом окинуть нельзя, а скроллировать, как мне кажется не удобно. (Думал, может еще что-то упустил, поэтому решил уточнить)
О больших дискуссиях - мне кажется с ними вообще все плохо. Пока ни разу не видел решения, которое бы полностью устроило.
> О больших дискуссиях - мне кажется с ними вообще все плохо. Пока ни разу не видел решения, которое бы полностью устроило.
У меня, как водится, есть идеи.
Если бы еще я не был таким распиздяем...
:)
У меня тоже есть мысля-другая, но думаю здесь не только распиздяйство - надо ведь не только придумать, но и реализовать, потом где-то опробовать и заточить. А просто так, в сундучок, код тоже писать не хочется.
дело в том что ruby/hipster вполне позволяет мне сделать несколько мелких-но-полезных приложений за считанные часы. и у меня их ровно 6 запланировано на "ближайшие дни" :-\
в том числе, proof-of-concept вариант sunaj (это Janus наоборот) однозначно делается дня за 3.
но сначала надо зарелизить хипстер, для чего довести его до ума местами и довести до ума доки.
но сначала надо выполнить текущий объем работы-за-деньги, что занимает дня 2 в неделю. остальные 5 занимает исключительно распиздяйство, увы.
Отправить комментарий