Комментарии 12
думаю YUI3 Вам понравится
Быть может, вы имели в виду CommonJS Modules/1.0 :)
$('').appendTo('body');
Медленно жарить в кипящей смоле за такой код…
Медленно жарить в кипящей смоле за такой код…
$('<div id="'+library.name+'"></div>').appendTo('body');
Ну вы поняли, да?
Ну вы поняли, да?
а с чего это ресайз в ядре находится?
а с чего это ядро привязано к дому?
нафига каждому модулю по диву? а если ему не нужен див? а если ему нужно 2 дива?
а с чего это ядро привязано к дому?
нафига каждому модулю по диву? а если ему не нужен див? а если ему нужно 2 дива?
Неплохая попытка получить «слабую связанность». Но ещё все впереди :)
1. Все сильно завязано на jQeury — нужен враппер
2. Модули знают что
3. Нужно убрать smth.onResize («Оповещение о каких-либо событиях системы») модули могут слушать эвент «resize». Вообще модулям достаточно иметь 2 метода:
Мне не очень нравится способ «саморегистрации» модулей. Если модуль подчиняется ядру, то почему он ему приказывает «Эй, ядро, это Модуль1 пришел — впиши меня!». Ядро должно быть авторитарным.
У ядра есть список модулей из которых состоят приложение. Ядро загружает модуль каким-либо образом (асинхронно или при препроцессинге), вписывает, запускает, убивает. Модуль должен просить разрешения на все действия вне контекста(«DOM элемента»).
— Модуль1: «хочу послушать событие resize, можно?»
— Ядро: «нет, ты bacground процесс тебе нельзя!»
ну или как-то так
1. Все сильно завязано на jQeury — нужен враппер
2. Модули знают что
$ и $("script[id=core]") есть в глобалах — кроме контекста модуль ничего не должен знать3. Нужно убрать smth.onResize («Оповещение о каких-либо событиях системы») модули могут слушать эвент «resize». Вообще модулям достаточно иметь 2 метода:
init() и destroy()Мне не очень нравится способ «саморегистрации» модулей. Если модуль подчиняется ядру, то почему он ему приказывает «Эй, ядро, это Модуль1 пришел — впиши меня!». Ядро должно быть авторитарным.
У ядра есть список модулей из которых состоят приложение. Ядро загружает модуль каким-либо образом (асинхронно или при препроцессинге), вписывает, запускает, убивает. Модуль должен просить разрешения на все действия вне контекста(«DOM элемента»).
— Модуль1: «хочу послушать событие resize, можно?»
— Ядро: «нет, ты bacground процесс тебе нельзя!»
ну или как-то так
Если бы я в рамках статьи начал писать еще и враппер, то я думаю понятнее она бы не стала, jQuery можно расценивать как псевдокод.
Про список модулей: в моей реальном проекте как раз так и реализовано, для каждого пользователя в зависимости от прав приходит json со списком доступных библиотек и всех ее свойств.
Я считаю что не нужно усложнять движок без необходимости для простых примеров, если все учесть — это не статью, а книгу писать надо.
Про список модулей: в моей реальном проекте как раз так и реализовано, для каждого пользователя в зависимости от прав приходит json со списком доступных библиотек и всех ее свойств.
Я считаю что не нужно усложнять движок без необходимости для простых примеров, если все учесть — это не статью, а книгу писать надо.
Почему в ядре завязка на DOM?
Потому что ядро не сферическое в вакууме, а работает тесно с DOM, вот верстку выносить в ядро точно нельзя, а контекст модуля расценивайте как tform в делфи. Ядро же должно уметь скрыть окно модуля, изменить размер, если например мы его развернули. Переключить фокус на другое окно. В делфи и .net приложениях этим занимается winapi по средствам событий, которые приходят форме. А в вебе я бы вынес это в ядро. Можно конечное сделать класс для низкоуровневой работы с окнами, но зачем же так усложнять для просто примера
Если у вас цель написать свой фреймворк, вместо разработки ERP на которую вам дали срок 2 месяца – то начните с ОС… или с архитектуры процессора… а почему нет!?
Все очень просто — заморочиться над архитектурой процессора на пару месяцев гораздо интереснее, чем разрабатывать мифическое ERP, а через два месяца все равно получить по шапке.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Модульное проектирование RIA проектов