Модульное проектирование RIA проектов

[AndrewStephanoff]

думаю YUI3 Вам понравится

[qmax]

wiki.commonjs.org/wiki/CommonJS

[azproduction]

Быть может, вы имели в виду CommonJS Modules/1.0 :)

[qmax]

ну я вообще намекал автору, что он не одинок в своих изысканиях.

[s0rr0w]

$('').appendTo('body');

Медленно жарить в кипящей смоле за такой код…

[s0rr0w]

$('<div id="'+library.name+'"></div>').appendTo('body');

Ну вы поняли, да?

[tenshi]

а с чего это ресайз в ядре находится?
а с чего это ядро привязано к дому?
нафига каждому модулю по диву? а если ему не нужен див? а если ему нужно 2 дива?

[azproduction]

Неплохая попытка получить «слабую связанность». Но ещё все впереди :)
1. Все сильно завязано на jQeury — нужен враппер
2. Модули знают что $ и $("script[id=core]") есть в глобалах — кроме контекста модуль ничего не должен знать
3. Нужно убрать smth.onResize («Оповещение о каких-либо событиях системы») модули могут слушать эвент «resize». Вообще модулям достаточно иметь 2 метода: init() и destroy()

Мне не очень нравится способ «саморегистрации» модулей. Если модуль подчиняется ядру, то почему он ему приказывает «Эй, ядро, это Модуль1 пришел — впиши меня!». Ядро должно быть авторитарным.
У ядра есть список модулей из которых состоят приложение. Ядро загружает модуль каким-либо образом (асинхронно или при препроцессинге), вписывает, запускает, убивает. Модуль должен просить разрешения на все действия вне контекста(«DOM элемента»).
— Модуль1: «хочу послушать событие resize, можно?»
— Ядро: «нет, ты bacground процесс тебе нельзя!»
ну или как-то так

[freeart]

Если бы я в рамках статьи начал писать еще и враппер, то я думаю понятнее она бы не стала, jQuery можно расценивать как псевдокод.
Про список модулей: в моей реальном проекте как раз так и реализовано, для каждого пользователя в зависимости от прав приходит json со списком доступных библиотек и всех ее свойств.
Я считаю что не нужно усложнять движок без необходимости для простых примеров, если все учесть — это не статью, а книгу писать надо.

[Panya]

Почему в ядре завязка на DOM?

[freeart]

Потому что ядро не сферическое в вакууме, а работает тесно с DOM, вот верстку выносить в ядро точно нельзя, а контекст модуля расценивайте как tform в делфи. Ядро же должно уметь скрыть окно модуля, изменить размер, если например мы его развернули. Переключить фокус на другое окно. В делфи и .net приложениях этим занимается winapi по средствам событий, которые приходят форме. А в вебе я бы вынес это в ядро. Можно конечное сделать класс для низкоуровневой работы с окнами, но зачем же так усложнять для просто примера

[Bobos]

Если у вас цель написать свой фреймворк, вместо разработки ERP на которую вам дали срок 2 месяца – то начните с ОС… или с архитектуры процессора… а почему нет!?

Все очень просто — заморочиться над архитектурой процессора на пару месяцев гораздо интереснее, чем разрабатывать мифическое ERP, а через два месяца все равно получить по шапке.