Изобретение своего «уникального» велосипеда я считаю очень полезным, если: он не отвлекает от работы (или отвлекает, но не сильно); дает новый положительный опыт; результаты можно где-то использовать; Сам процесс - это взрыв.
Именно с этого я и начал, когда 3 года назад начал проектировать свой «байк» и, наверное, переписывал его раза 3-4 по сей день.
Все началось с загрузчика и JQ
RequireJS — безусловно, хорошая и очень эффективная утилита, позволяющая очень быстро и легко организовать модульную систему на стороне клиента.И она меня устроила всем, кроме двух моментов:
- "появление"
- система кэширования.
А когда модулей становилось все больше и больше, это превратилось в какое-то безобразие.requirejs(["module_0", "module_1"], function(module_0, module_1) { });
С одной стороны, вы можете вызвать нужный модуль где-то внутри кода (если он используется очень и очень редко), с другой стороны, вам хотелось бы видеть все зависимости родительского модуля в одном месте.
Кроме того, меня немного раздражала необходимость при объявлении зависимостей оперировать путями, а не переменными, содержащими необходимые данные.
Нет, можно, конечно, где-то объявить глобальный объект с путями и привести всё примерно к такому (но всё равно как-то некрасиво): requirejs([modules.mod_0, modules.mod_1], function(module_0, module_1) {
});
Что касается управления кэшем, то оно мне показалось, скажем так, неявным.
Со временем я начал разрабатывать требования к собственному загрузчику, и сегодня они сформулированы следующим образом:
- все файлы JS и CSS должны быть кэшированы, а система кэширования должна иметь явные и понятные элементы управления.
- Модули, объявленные в приложении, должны быть объявлены в одном конкретном месте (едином регистре).
- Объявление зависимостей модулей друг от друга должно происходить без использования путей, а с использованием ссылок на один регистр (пункт 2) или имен модулей.
- должен быть контроль порядка загрузки модулей, а также возможность асинхронной прокачки необходимых ресурсов.
Ядро состоит из трёх файлов, названия которых ясно указывают на их назначение:
Обратите внимание, что вам нужно только подключить [flex.core.js], и реестр модулей и настроек подхватится автоматически.Но вот и первая плохая новость.
Разработчик строго привязан к названиям файлов и их расположению.
[flex.registry.modules.js] и [flex.settings.js] должны находиться в том же месте, что и основной модуль [flex.core.js], и их имена нельзя изменить.
Но так как это мой байк и я пока единственный разработчик, то это обстоятельство меня особо не беспокоит. Кроме того, такая организация меня очень устраивает. Уже есть десяток проектов, написанных на flex, и я всегда знаю, где найти настройки и полный список используемых модулей.
Итак, давайте взглянем на [flex.registry.modules.js] (реестр модулей из живого проекта).
flex.libraries = {
//Basic binding controller
binds : { source: 'KERNEL::flex.binds.js', hash: 'HASHPROPERTY' },
//Basic events controller
events : { source: 'KERNEL::flex.events.js', autoHash: false },
//Collection of tools for management of DOM
html : { source: 'KERNEL::flex.html.js'
Теги: #JavaScript #CSS #HTML #шаблоны #движок шаблонов #CSS #JavaScript #HTML
-
Как Заблокировать Ip-Адреса Через Ufw
19 Oct, 24 -
Все О Cisco Fastlocation
19 Oct, 24 -
Google Растет В 4 Раза Быстрее Яндекса
19 Oct, 24 -
Установка Симулятора Ios 4.2 В Xcode 4.3
19 Oct, 24 -
Api Яндекс Лингвистики Для .Net
19 Oct, 24 -
Dvcs И Dag
19 Oct, 24
