![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Dojo Framework
Вялотекущие архитектурные изыскания вышли в стадию активного прототипирования клиентской части. Очень хотелось найти JS-фреймворк, одновременно предоставляющий достаточный уровень абстракции над DOM, единообразную поддержку разных событий, средства моделирования данных (чтобы не возиться с прикручиванием Backbone, Knockout и прочих), инструменты для разработки UI-компонент и обладающую уже готовым набором этих компонент. Искать пришлось довольно долго.
Довольно быстро с дистанции сошли SproutCore (который теперь Ember), Qooxdoo, dHTMLx, SmartClient, Rico. Туда же пошли монстры вроде AppCraft.
В финал вышли: jQuery UI, ExtJS, Dojo и YUI3. Отбросил YUI3, потому что где будет Yahoo даже через полгода - совсем непонятно, плюс даже третья версия показывает признаки старости. jQuery UI выглядел неплохо, но разработка его как целого тулкита у меня вызывает лёгкое недоумение (они там похоже простое дерево третий год пишут). ExtJS, особенно четвёртая его инкарнация, очень хорош, однако его лицензионные заморочки настораживают даже меня (а что скажут юристы?!). И остался Dojo Toolkit.
Пристальное изучение самого свежего Dojo 1.7 показало, что это офигенный фреймворк, незаслуженно обделённый вниманием в интернетах. Поначалу конечно подсознательно сравниваешь его с jQuery и огорчаешься от необходимости писать столько много буковок. Но когда понимаешь, что приобретаешь за такую небольшую цену - приходит настоящее счастье. Итак, что мы имеем в бонусах?
- Продуманную модульность с асинхронной загрузкой (AMD-compliant). Есть компактное микро-ядро, которое умеет грамотно подгружать всё остальное, разрешая зависимости на лету.
- Неплохой инструментарий для работы с DOM. Конечно всё не так изящно, как в jQuery, но привыкнуть можно. Можно делать запросы селекторами и скармливать результаты итераторам и прочим map'ам и reduce'ам. (Для фанатов - есть всякая продвинутая функциональщина.)
- Полная модель событий. На элементах поддерживаются как DOM-события, так и свои собственные. Плюс есть глобальный механизм pub/sub по именованным топикам.
- Есть средства моделирования данных (data stores) с набором готовых хранилищ поддерживающих JSON, CSV, OPML, YQL, RDF и др. Хранилища умеют интегрироваться с другими компонентами, вроде таблиц или графиков, обеспечивая живое обновление на лету.
- В Dojo имеется удобный механизм для создания независимых виджетов ("dijits") и в комплекте поставляются десятки уже готовых виджетов разной степени завершённости: средства layout'a, диалоговые окна, продвинутые формы, многофункциональные таблицы и деревья, всяческие менюшки, графики, карты и многое-многое другое.
- Графическая подсистема с поддержкой анимации. Помимо кросс-браузерной поддержки векторной графики, в Dojo есть и весьма обширная библиотека диаграммных компонент вполне на уровне лучших платных JS-библиотек. Те, кому вдруг не хватит встроенных средств визуализации, смогут легко дополнить библиотеку своими собственными модулями - это довольно несложно.
- Есть методология поддержки тем оформления - как для виджетов, так и для диаграмм, с возможностью подменять темы на лету.
- Заявлена поддержка мобильных интерфейсов - для клиентов на iOS, Android и Blackberry. Пока не тестировал, но хочется верить что поддержка достойная.
Есть в Dojo и ещё одна крайне любопытная фича - декларативный стиль создания страниц. Работает это так: в заголовке страницы указывается флаг для подключения dojo-парсера, а затем в теле страницы создаются теги которые на лету будут заменяться на виджеты согласно свойствам описанным в атрибутах тегов (как раз в HTML5 не так давно узаконили data attributes).
Надо заметить что во всей этой бочке мёда имеется и ложка говна дёгтя. Мне кажется, что проблемы проистекают из того что это проект, создаваемый программистами для программистов. Соответственно первая проблема - это непостоянство API. Вероятность того, что найденный в интернетах пример на Dojo заработает на классах 1.7 с первого раза - мягко говоря невысокая. Где-то просто поменялись аргументы, где-то классы переехали между namespaces, а где-то и просто нет обратной совместимости. Показательно: берём примеры с официального сайта из раздела tutorials, запускаем их и видим в JS-консольке предупреждения о deprecations. То есть как только выйдет обещаемая версия Dojo 2.0 - нас опять будут ждать весёлые времена. И сюда же примыкает вторая громадная проблема - отсутствие внятной документации. Вероятность обнаружить полную документацию по, скажем, аргументам конструктора класса из dojox.*, стремится к нулю. На официальном сайте иногда можно найти примеры использования классов, иногда - подробный tutorial, но как правило страница документации содержит стандартное "class Foo наследуется от FooBase, создаётся foo = new Foo и делает Foo". То есть пользоваться Dojo без тщательного изучение всех исходников - скорее всего не получится. Насколько это плохо - придётся решать каждому девелоперу самому. Лично я пока ещё в глубоких раздумьях.
Вообще, похоже что Dojo - проект с трудной судьбой, ведущий свою историю с лохматого 2004 года. Так что пишется он давно, в разработчиках в разное время засветились IBM, AOL, Sun и другие конторки помельче. Однако, похоже что пару раз в процессе развития им приходилось отказываться от совместимости назад, что не добавляло популярности. А в районе 2008 года их чуть было не запинал jQuery, но ребята нашли силы и средства дать отпор. И, хочется верить, продолжат движение вперёд. Дополнительную надежду даёт наличие в разработчиках нашего бородатого дядьки по имени Eugene Lazutkin. :)
Резюмируя, в общем Dojo мне понравился и, если не наткнусь на что-то совершенно фатальное, буду строить UI именно на нём. Если у кого будут вопросы по Dojo - приходите обсуждать на ХэшКод или на StackOverflow.
no subject
- там же, вроде, тоже есть ядро и отдельные блоки, только набирать нужно самому.
no subject
no subject
Увы, моя душа уже развращена нокаутом, так что - нет. Dojo это прошлый век.
Возьмем типичный пример. Допустим, нужно нарисовать некую табличку (грид) с фильтрами и сортировками. Данные для этой таблички динамически запрашиваются ajax-ом с сервера в виде json. Юзер может что-то в этой табличке поправить, соответственно нужно сохранять изменения всё тем же ajax-ом c json-ом через новомодный REST.
На первый взгляд, в Dojo всё здорово. Есть навороченный Grid со всеми свистелками и перделками, есть хранилище (store), в котором лежат данные таблицы в виде почти обычных js-объектов. Грид умеет самостоятельно обновляться при изменению объектов в хранилище и наоборот. Кроме того, в Dojo есть хранилище JsonREST, которое умеет само синхронизироваться с сервером при помощи json и REST. Казалось бы, красота - берем два готовых компонента, настраиваем, ???, PROFIT! И ни одной строчки HTML кода.
Но это только на первый взгляд.
Берём туториал, смотрим настройку грида.
Вот кусочек, отвечающий за описание одного столбца таблицы:
{ name: "Bats", field: "bats", width: "70px", cellStyles: "text-align: right;" }
Ну это нормальный стиль для программистов десктопных приложений. Но не для веба. Ну даже закроем глаза на явное указание width и стиля, будем считать что это не быдлокод, а сделано для простоты восприятия.
Но! Dojo здесь работает как прослойка с ООП-синтаксисом, которая генерирует html-код. Нафига? Зачем описывать то, что должно быть в html коде? Почему не использовать собственно html-код, как в нокауте? Сферический веб-программист в вакууме отлично знает html, css, чистый javascript. А вот библиотеку dojo - не знает, и по словам recorder-a доки есть не на всё. Вообще, каков смысл существования этой прослойки?
Дальше, про заявленные рюшки типа пейджинга, сортировки и фильтров. Грид сам этого не делает, предоставляя работать хранилищу. Это в-общем разумно. Но! Далее хранилище JsonREST этого тоже не делает, оно сбрасывает всё на сервер. А вот это уже опаньки. Дергать сервер каждый раз, когда юзер прокручивает таблицу - это за гранью. И второе - придется допиливать сервер, чтобы научить его делать пейджинг с сортировкой. Тоже не айс.
Не, ну они приводят пример таблицы со 100500 строками, и типа у них все работает. Извините ребята, но это бред. Таких таблиц не должно быть ни в вебе, ни в десктопных приложениях. Человек не способен воспринять таблицу не то что на сто тысяч строк, даже на сто уже с трудом. Ну максимум - тысяча. Дорабатывайте UI своего приложения так, чтобы таблиц длиннее 1000 строк у вас не было в принципе. Разбивайте данные по группам, по годам, давайте сводные итоги, как хотите. Оставшиеся тысячу строк должны передаваться на клиенте целиком, и их сортировкой должен заниматься клиент, а не сервер.
Это всё конечно решаемо. Можно написать своё хранилище с сортировками и собственным Json... Или перелопатить исходный код и найти, как настроить имеющийся компонент. Только желания как-то не возникает.
no subject
Я не один год мучился с абсолютно резиновыми таблицами, так что теперь когда вижу явное описание табличного layout'a - сразу испытываю облегчение.
Опять же по моему опыту: есть системный программист, который ваяет html/css/js и есть прикладной программист, который знает какие поля должны быть в форме, как они должны взаимодействовать и пр. Так вот первому не очень интересны бизнес-вопросы, а второй обычно хреново знает html/css. И введение этой "прослойки" помогает эффективно использовать обоих.
В моём случае, дёргать сервер при смене просматриваемой страницы - это именно то, что мне нужно. Разумеется, грузить 100500 строк на клиента и их там сортировать - полный бред, однако если встаёт задача таки-обеспечить доступ к структурам из тысяч строк (и нет возможности влиять на такие требования) - это идеально решает мою задачу.
Резюмируя: мои задачи компоненты Dojo решают очень хорошо, а ваши - могут и не решить. YMMV.
no subject
Dojo предполагает, что можно взять программиста бизнесс-процессов, всю жизнь писавшего на .net/java/1C/younameit, и он сразу со всем разберется. Извините, но практика показывает, что в результате такого подхода получится тормозная глючная какашка. Что мы и наблюдаем с Dojo, даже демки которого грузятся секунды по три и глючат при изменении размера браузера.
Всё же прежде чем писать production-код под незнакомое окружение с незнакомым видом программирования, неплохо бы немного почитать мануалы и поиграться в песочнице.
Никто не заставляет прикладного программиста разбираться в тонкостях рассчета разнозначных margin-ов для плавающих элементов в IE. Для этого есть верстальщик. Прикладнику достаточно изучить базовый html синтаксис, буквально 10 тегов (div,span,table,tr,td,th,ul,ol,li,form, input - уже достаточно). Но если прикладник начинает вставлять в свою бизнес-логику куски стилей, тупо копируя непонятную абракадабру - результат будет плачевен. Что, если вам понадобится изменить ширину колонки? добавить вертикальное выравнивание? сделать рамочку по левому краю ячеек? Верстальщик будет объяснять прикладнику, какие стили нужно прописать в коде? Ау, CSS придумали лет 20 назад! Я не против жесткого задания ширины колонки, я против задания этой ширины в конструкторе объекта бизнес-логики!
Есть конечно путь GWT, где вообще всё изменение внешнего вида перегружено отдельной прослойкой, и для изменения скажем ширины ячейки нужно сделать mygrid.getCellFormatter(x,y).setWidth("100px"). Особенно этот путь продуктивен, если нужна поддержка разных тем оформления или разных языков.
В-общем, imho, dojo это такой велосипед, разросшийся до масштабов авианосца. Нет, он, безусловно, ездит, но...