Dojo Build System, собственный опыт создания сборки

Dojo — не самый популярный JavaScript фреймворк, несмотря на все свою мощь и положительные качества. Информация, которую я хочу донести сегодня до читателя, требуется для абсолютно каждого проекта, построенного с использованием этой технологии.

А поговорим мы о системе сборки.

Что это и зачем это нужно

Сообщество предлагает нам уже готовый оптимизированный релиз, предназначенный для размещения на сервере и использования в веб-приложениях. Подключая необходимые модули через dojo.require() мы инициируем синхронные HTTP GET запросы для получения необходимых ресурсов. Так как браузер ожидает завершения каждого вызова, то время загрузки страницы серьезно увеличивается. Оптимизировать подключение ресурсов нам помогут так называемые “layers” (далее просто — слои).

Задачи использования dojo build system для создания собственной сборки:
  • создание слоя используемых модулей. Все нужные модули соберутся в 1 файл, что заметно ускорит открытие страниц
  • при необходимости изменений кода модулей dojo мы будем всегда работать только с исходным кодом (src-версий dojo)
  • при наличии таких изменений действия по их встраиванию в очередные обновления сводятся к минимуму

Что необходимо для создания сборки

  • Src-версия dojo, которую можно найти на странице загрузки
  • JRE 1.5 и выше
  • Опционально, собственные ресурсы (js, css и тд), которые мы хотим включить в сборку.
  • Профиль (profile) – js файл, который описывает создание новой сборки.
  • Движок Rhino от Mozilla Foundation. Dojo в свои утилиты для сборки его не подложил, хотя активно на него ссылается. Взять можно на сайте Mozilla

Создание слоев

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

dojo.provide("ourcompany.commonlayer");

//основные модули
dojo.require("dojo.parser");
dojo.require("dojo.NodeList-fx"); 
dojo.require("dojo.data.ItemFileReadStore");
dojo.require("dojox.data.AndOrReadStore");
dojo.require("dojo.back");
dojo.require("dojox.fx._base");
dojo.require("dojo.cookie");

//специфический
dojo.require("ourcompany.shadow");

ourcompany.shadow – допустим, это наш собственный модуль, кастомизация тени dojo.fx.shadow, которую мы хотим использовать.

И для сравнения дополнительный слой по работе с редактором dijit.Editor:

dojo.provide("ourcompany.editorlayer");

//подключение самого редактора и плагинов
dojo.require("dijit.Editor");
dojo.require("dijit._editor.plugins.FontChoice"); 
dojo.require("dijit._editor.plugins.TextColor");
dojo.require("dijit._editor.plugins.EnterKeyHandling");

//специфический
dojo.require("ourcompany.dijit._editor.plugins.LinkDialog");

Мы меняли плагин вставки ссылки LinkDialog под собственные нужды. Выносим его из стандартной сборки и обзываем по-своему, как в случае с тенью. Смена названия происходит просто: исходный js код плагина добавляется строчка с новым объявлением, например:

dojo.provide("ourcompany.dijit._editor.plugins.LinkDialog");

где название ourcompany.dijit.… также говорит о физическом размещении модуля в файловой системе, \ourcompany\dijit\_editor\plugins\LinkDialog.js

Создание профиля

В профиле layers.profile.js описываются необходимые слои и области именования, в объекте dependencies:

 dependencies = {
        layers: [
		
		//описание наших двух слоев
		{
			name: "../ourcompany/commonlayer.js",
			resourceName: "ourcompany.commonlayer",
			dependencies: [
				"ourcompany.commonlayer"
			]
		},
		{
			name: "../ourcompany/editorlayer.js",
			resourceName: "ourcompany.editorlayer",
			dependencies: [
				"ourcompany.editorlayer"
			]
		}
	],

    prefixes: [
        //система знает, где искать папку /dojo, а остальные надо ей показать
        //ourcompany - директория с нашими кастомизациями и ресурсами
        [ "dijit", "../dijit" ],
        [ "dojox", "../dojox" ],
        [ "ourcompany", "../ourcompany" ]
    ]
}

Такой файл создаст только оптимизированные 2 слоя, остальные файлы просто скопируются при сборки без изменений. Но их мы можем взять из официального релиза. Возможно у кого-то будет желание дополнить профиль так, чтобы он создавал полную сборку dojo, я не стал.

Собираем

В src-версии dojo есть особенная папочка util, в которой можно найти скрипты сборки и утилиту shrinksafe для обфускации (оптимизирования) кода. Но не обольщайтесь, «из коробки» это не работает. Пришлось вникать и побеждать. Dojo предлагает два варианта сборки, для Windows через build.bat и для linux через build.sh. Сборку я проводил на родном компьютере, в окнах.

Непосредственно процесс сборки запускает файл \util\buildscripts\build.bat. Отредактируем его, указав правильный -classpath:

java -classpath "../rhino/js.jar;../shrinksafe/js.jar;../shrinksafe/shrinksafe.jar" org.mozilla.javascript.tools.shell.Main build.js %*
pause


где rhino — java-движок, о котором я говорил выше.

Запустить сборку, указав параметры, удобно через makeRelease.bat файл. Я сделал это так, но я не специалист в написании батников, думаю у вас выйдет изящнее:

@echo off

E:
cd \js\dojoroot

set FLDR=E:\js\dojoroot
echo buid root directory: %FLDR%

cd %FLDR%\dojo-release-1.6.0-src\util\buildscripts
build.bat action=clean,release profileFile=%FLDR%\layers.profile.js version=ourcompany-1.6.0/2 releaseName=


В файловой системе это выглядит так:
директория dojoroot

Как видите, сборку я проводил из исходников, директория «dojo-release-1.6.0-src», в которую подложил папку «ourcompany» с измененными модулями и ресурсами. Для запуска build.bat я использую следующие аргументы:
  • action — необходимые действия, clean — очистить старую директорию сборки, release — создать сборку
  • profileFile — путь к профилю
  • version — версия сборки, можно будет возвращать через dojo.version
  • releaseName — у меня пустое, если его задать, в папке release появится поддиректория с вашим названием

Полный список аргументов есть в документации.

После выполнения сборки директория приобретет вид:
директория с исходниками и релизом

В release лежит практически новогодний подарок — наша первая кастомная сборка dojo. В \release\ourcompany\ находятся два наших слоя, каждый из которых представляет собой оптимизированную могучую кучку из необходимых нам модулей для подключения.

Подключение слоев на страницу проекта:

<!-- Как и раньше требуется подключение ядра dojo:-->
<script type="text/javascript" src="dojo/dojo.js"></script>

<!-- Затем подключается общий для всех страниц слой: -->
<script type="text/javascript" src="ourcompany/commonlayer.js"></script>

<!-- Для страниц, где используется редактор, подключаем: -->
<script type="text/javascript" src="ourcompany/editorlayer.js"></script>

Работа со слоями не исключает стандартной работы с модулями через dojo.require(). Необходимо отметить, что перед подключением dojo.require() проверяет, подключался ли уже такой модуль, и предотвращает повторное подключение.

Результат

Данная статья не только продукт глубоких умозаключений и творческого поиска, а реальный опыт, примененный в реальном веб-проекте. Что мы получили после создания и использования собственной сборки:
  • существенно выросла скорость загрузки всех страниц. Время загрузки по личным наблюдениям в Firebug и тестам webpagetest.org сократилось примерно на секунду
  • на главной странице проекта, где не используется редактор, 129 последовательных HTTP GET запросов превратились в один (sic!)
  • проект пережил обновление с dojo 1.4 на версию 1.6, и теперь легко будет обновляться на каждую новую версию

P.S. Внесение изменений в модули dojo часто несет за собой некоторые сложности с зависимостями. Например, при изменении плагина LinkDialog.js для dijit.Editor, который мы включили в сборку, потребовалось внести в src-версию папки ourcompany стандартные файлы ourcompany\dijit\nls\ru\common.js (loading.js). Без этой манипуляции слой editorlayer.js будет работать с ошибкой.

При изучении механизма создания сборок я использовал документацию на официальном сайте dojo toolkit:
http://dojotoolkit.org/reference-guide/build/
http://dojotoolkit.org/reference-guide/build/simpleExample.html
http://dojotoolkit.org/reference-guide/build/buildScript.html
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 20

  • НЛО прилетело и опубликовало эту надпись здесь
      0
      ну, у меня сделана как раз пхп-лайк с автолоадом и автоматическим контролем зависимостей х3
        0
        Я как раз сейчас пишу статью про это, будет интересно сравнить подходы.
        Так что пилитепишите
          0
          мне больше нравится модульная система YUI3
          0
          А насколько широко вы используете Dojo? Можете подсказать хорошую доку для библиотеки? Когда ее смотрел пару месяцев назад, для многих виджетов было только фрагментарное описание, разобраться было совсем непросто.
            0
            В основном, активно используем ядро. Запросы в духе dojo.query(), подключение событий, анимация, AJAX и многие другие приятные мелочи. А также немного из диджитов и dojox.
            В последнее время изучаю dojox.mobile для построения веб-приложения под ipad.

            Доки на сайте тулкита и на кампусе (там же есть старый престарый feature explorer, немного тоже может помочь)
            А еще есть форум сообщества, на котором мне не раз помогали.

            Раньше доджо славилось недостатком информации и доков. Сейчас получше.
              0
              Почему Dojo, а не JQuery или ExtJS?
                0
                Я не стоял у истоков разработки нашей системы. Пришел уже как специалист с опытом работы по dojo. Проект организован на платформе IBM Lotus Domino, и ее связка с dojo довольно популярна.
                  0
                  А как оцените весь этот инструментарий по сравнению с аналогами из mooTools / jQuery? Там, где аналогичная функциональность есть
                    0
                    мои сведения о других фреймворках весьма поверхностны. Не могу сравнить, но не думаю что по факту сильно отличается, или лучше\хуже
                      +1
                      Первое (но не единственное) — виджеты. Во-первых стандартные dijit, на большинство случаев жизни:
                      dojotoolkit.org/widgets

                      Во-вторых, возможность реализовать свои custom widgets:
                      www.enterprisedojo.com/2010/09/21/introduction-to-custom-dojo-widgets/
                      , причем достаточно просто (вплоть до того, что я в своём текущем проекте реализовал через custom widgets целиком разные экраны приложения).

                      В целом, после JQuery — мне очень нравится. Не в том смысле, что JQuery хуже, а в том что для моих задач Dojo подходит намного лучше.
                      С документацией пока хуже, чем с JQuery, это да. Но разобраться вполне можно — не смертельно.
                      0
                      Она не просто популярна, dojo входит в стандартную поставку IBM Domino, интерфейс на базе XPages также широко использует визуальные компоненты этого фреймворка.
                0
                «Dojo — не самый популярный JavaScript фреймворк»
                Я догадываюсь почему. JS тем и популярен, что позволяет девелоперу стартовать проект только с блокнотом и браузером в руках. А тут… Консоль, джава, сборка, конфигурации, баши и пакетные файлы… Я пробовал dojo mobile и после 2х минут свистопляски в консоли с питоновскими скриптами — плюнул, скопипастил с другой папки sencha и начал её юзать. Почему Sencha при всём подобном функционале не требует подобной свистопляски? В чём выигрыш такого излишне сложного подхода? Как по мне — поддерживать и вносить изменения в пакет в разы сложнее.
                  0
                  «Внесение изменений в модули dojo часто несет за собой некоторые сложности с зависимостями.»
                  Вот вы и сами об этом же пишете… Странная философия у фреймворка. Что подходит серверным руби/джава/пхп проектам, то выглядит крайне странно для javascript.
                    0
                    тут я к своему стыду пошел по плохому пути. На самом деле не желательно вносить изменения в пакеты, а грамотно расширять и добавлять свои собственные диджиты.
                    0
                    То, что касается сборки и джавы — это всё КОНЕЧНЫЙ этап разработки приложения. Т.е. в идеале это вообще делается только для релиза. А для каких-то простых задач можно и вовсе обойтись.
                    (насчет dojo _mobile_ не знаю, разве там что-то принципиально отличается от других пакетов?)
                    +1
                    Согласен, с dojo много проблем, с тем же mobile'ом (начинаю пить валерьянку, mobile сыроват).
                    jQuery и т.п. не хуже, как фреймворки для разработки веб-приложений.

                    Dojo выбирают, когда нужно построить сложную артитектуру большого приложения, расширить его своими виджетами и тп. На самом деле он предлагает много системных решений и подходов,… о которых я даже не знаю, потому что работаю на уровне пользователя девелопера, расширяющего сервисы системы.
                      0
                      Вот, совершенно согласен. Dojo именно для реализации каких-то серьезных приложений. А привинтить какую-то функциональность к сайту — проще с помощью JQuery (например) и подходящих плагинов к нему.
                        0
                        я в своё время выбирал между Dojo и YUI3 и остановился на YUI3
                      0
                      Кстати, использовать систему сборки Dojo можно и без самого Dojo. Т.е. только минимальный код включается — для поддержки provide/require/ajax/deferreds, а остальное может быть jQuery/Sencha/whatever ;)

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое