Comments 27
> В модели Закаса бизнес логика и UI реализуется в песочнице и отчасти в ядре.
Разве?
Насколько я знаю, всё (UI и бизнес-логика) содержится в модулях, ядро и песочница служат только для оперирования модулями (создание/отключение, event managment, работа с правами доступа).
Песочница служит только одной глобальной цели — идентификация модуля, а это в свою очередь нужно для разграничения прав доступа.
Разве?
Насколько я знаю, всё (UI и бизнес-логика) содержится в модулях, ядро и песочница служат только для оперирования модулями (создание/отключение, event managment, работа с правами доступа).
Песочница служит только одной глобальной цели — идентификация модуля, а это в свою очередь нужно для разграничения прав доступа.
Да, вопрос хороший. Если помещать всё в модули, то модель Закаса почти сведется к MVC, где песочница — другое название Контроллера. Мне кажется, есть некоторая логика, которая неизбежно будет в ядре, а именно, когда перерисовка интерфейса фиксирует несколько модулей. Хотя я могу ошибаться.
Текст поправлю позже, когда наступит более четкое понимание.
Текст поправлю позже, когда наступит более четкое понимание.
Не согласен.
Модуль в данном случае содержит и Model, и View, и Controller.
Ядро в данном случае выступает фреймворком, который всё это поддерживает, а песочницы реализуют какое-то подобие FrontController'a, через который проходит общение с другими модулями и с ядром.
В данном случае это не является плохой практикой смешивать эти три сущности, ибо всё же client-side разработка вносит свои коррективы, и собственно вьюшки для каждого отдельного модуля либо очень просты, либо их вообще нет.
Например, почтовый клиент — модуль «список писем», 1 вьюшка, 10 действий (action); модуль «список папок», 2 вьюшки, 10 действий; модуль «новое письмо», 1 вьюшка, 5 действий.
Собственно поэтому контроллер цепляем к модели и не паримся.
В ядре только логика работы с модулями + generic-event'ы, такие как resize/ready. Но всё эти event'ы просто транслируются подписанным модулям, буквально одна-две строчки.
PS: Говорю только из собственного опыта, большое-небольшое, но 10к строк написано :)
Модуль в данном случае содержит и Model, и View, и Controller.
Ядро в данном случае выступает фреймворком, который всё это поддерживает, а песочницы реализуют какое-то подобие FrontController'a, через который проходит общение с другими модулями и с ядром.
В данном случае это не является плохой практикой смешивать эти три сущности, ибо всё же client-side разработка вносит свои коррективы, и собственно вьюшки для каждого отдельного модуля либо очень просты, либо их вообще нет.
Например, почтовый клиент — модуль «список писем», 1 вьюшка, 10 действий (action); модуль «список папок», 2 вьюшки, 10 действий; модуль «новое письмо», 1 вьюшка, 5 действий.
Собственно поэтому контроллер цепляем к модели и не паримся.
В ядре только логика работы с модулями + generic-event'ы, такие как resize/ready. Но всё эти event'ы просто транслируются подписанным модулям, буквально одна-две строчки.
PS: Говорю только из собственного опыта, большое-небольшое, но 10к строк написано :)
> В MVC логика зашита в Контроллере.
Имхо логика должна быть в модели
Имхо логика должна быть в модели
Есть ли где-то более подробное описание реализации модели Закаса, желательно словами, а не видео? А то приходится догадываться о том, как он представляет перенос данных и команд между уровнями и сколько дополнительных прикладных языков существует в его системе, чтобы в конце осуществились слова "основываться на любой из стандартных библиотек типа jQuery и менять их без проблем". Иначе звучит очень рекламно, потому что библиотека — это язык выражения действий. Смена библиотеки — смена языка. А, простите, на чём тогда выражена модель? Очевидно, на своём языке, со своими понятиями. И «беспроблемная» смена библиотеки означает «всего лишь» замену методов одной библиотеки методами другой. Или дописывание своего «контроллера» библиотеки — транслятора языка данной библиотеки в свой. Хочется увидеть, где об этом говорится.
Согласен, мне тоже это показалось какой-то ересью. Вот использовал я MooTools, расширенные прототипы, его работу с DOM и всё остальное, а потом решил перейти на jQuery. Как это можно сделать легко? О, о
Легко не получиться. Смысл в том, что в ядре создается дополнительный уровень абстракции для управления методами библиотеки и плагинов. Поэтому при смене библиотеки или плагина достаточно переписать только ядро и не менять модули. Например, как-нибудь так
var Core = {};
Core.getElements = function( selector, context ){ return jQuery(selector, context||document); }//jQuery
Core.getElements = function( selector, context ){ return $(context||document).getElements(selector); }//Mootools
но ведь интерфейс у вернувшихся объектов разный
В этом и состоит задача ядра создать новый интерфейс для подключаемых библиотек. Насколько будет поменять библиотеку я себе слабо представляю. Это, как говориться, всего лишь идея. Знаю, точно, что в ядре очень хорошо оперировать со сторонними плагинами и менять их при необходимости.
а если декорировать возвращаемые объекты на уровне ядра?
И довольно трудно представить (точнее, не представляю), как транслируется представление (View) у него в Песочницу, а потом обратно, в требуемое представление. Вот, для примера. Есть у нас страница. Там разные блоки, стили, места для информации и для работы виджетов, и эти места пересекаются. Скажем, один виджет — показ кода, другой — подсветка кода в одном и том же блоке. Предлагается создать Песочницу, где тот же блок предстанет для первого скрипта как контейнер для текста, а для второго — как место для раскраски? Но ведь ясно же, что их действия пресекаются, какая здесь независимость? Ладно, по правилам Песочницы блок заполнили, раскрасили и ядро приложения переносит его обратно, в HTML. Можно представить себе, насколько тщательно ядро должно учитывать сособенности браузеров, чтобы отразить представление в Песочнице, а потом перенести обратно. (Я правильно понимаю модель поведения ядра?) И затем смотрим на результат и думаем, какие и на каком уровне допущены ошибки, почему и где у нас не получилось, как задумано. Вместо 2 предметов — виджет и объект — имеем Вид, Ядро, Песочница, Виджет (Модуль в его терминах). И ещё библиотека, с помощью которой написан Модуль — легко меняется. Значит, ещё имеем где-то в схеме Транслятор библиотеки в некий внутренний язык. 5 сущностей вместо 2. Так писать действительно легче?
Представление (VIEW) не содержится в схеме Закаса. Транслятор в ядре (в каком-то смысле ядро и есть транслятор, хотя предполагаются еще служебные функции).
Действительно ли писать легче — я на это не могу ответить. Кстати, Вы использовали MVC или MVVM в js?
Действительно ли писать легче — я на это не могу ответить. Кстати, Вы использовали MVC или MVVM в js?
Я писал на knockout в стиле MVVM.
А отсутствие слоя View я у него уже «исправил» (т.е. поставил туда, где оно могло бы стоять, правда, линия должна идти из ядра) и хочу предложить картинку немного по теме того, что обсуждается. И чуть ниже — почему я к ней пришёл.
Итак, есть ещё один путь построения архитектуры, я с ним познакомился не так давно, благодаря публикациям такой библиотеки: habrahabr.ru/blogs/javascript/133328/. Чтобы долго не искали суть, расскажу в 2 словах. Библиотека DOM-shim подходит к работе как с DOM, так и с моделью языка так, что создаёт мета-модель языка, близкую к новейшим стандартам, а остальные браузеры (практически все) подтягивает до понимания этой модели. И даёт работать в этой модели. Для самых далёких от модели браузеров ситуация будет выглядеть так, как на рисунке: они будут понимать задачу в песочнице, но транслятор не сможет её отобразить. И, как следствие, просьба заменить себя :).
В плане построения архитектуры — почему бы не взять за основу метаязык, близкий к стандартам?
А отсутствие слоя View я у него уже «исправил» (т.е. поставил туда, где оно могло бы стоять, правда, линия должна идти из ядра) и хочу предложить картинку немного по теме того, что обсуждается. И чуть ниже — почему я к ней пришёл.
Итак, есть ещё один путь построения архитектуры, я с ним познакомился не так давно, благодаря публикациям такой библиотеки: habrahabr.ru/blogs/javascript/133328/. Чтобы долго не искали суть, расскажу в 2 словах. Библиотека DOM-shim подходит к работе как с DOM, так и с моделью языка так, что создаёт мета-модель языка, близкую к новейшим стандартам, а остальные браузеры (практически все) подтягивает до понимания этой модели. И даёт работать в этой модели. Для самых далёких от модели браузеров ситуация будет выглядеть так, как на рисунке: они будут понимать задачу в песочнице, но транслятор не сможет её отобразить. И, как следствие, просьба заменить себя :).
В плане построения архитектуры — почему бы не взять за основу метаязык, близкий к стандартам?
Мне кажется, Вы немного ушли в частности. DOM-shim можно мыслить как плагин или как часть основной библиотеки. Аналогично Sizzle есть часть jQuery, и незачем выделять это в отдельный View. В основной библиотеке должна быть работа с сетью (XHR), работа с браузерными событиями и проч. техника — не будем же мы для каждого такого блока выделять отдельную логическую базу на схеме?
Да, часть основной библиотеки, тот самый необходимый метаязык. Точнее, заплатки, позволяющие реализовывать его во всех браузерах. (Можно считать язык абстрактным, но тогда смена языка изложения потребует переписывания всех программ.) У меня и был об этом вопрос — каков язык описания на клиентской стороне? Взятие его за основу позволит написать ядро и отвязаться от других библиотек.
Есть скринкаст-курс marketplace.tutsplus.com/item/writing-modular-javascript/128103/, платный.
Но я его пока не смотрел. Пока что я тоже понял Закаса в том смысле, что есть некоторый транслятор для стандартной библиотеки. Он может быть простейшим для начала: изменение переменной $ на 'lib', к примеру.
Но я его пока не смотрел. Пока что я тоже понял Закаса в том смысле, что есть некоторый транслятор для стандартной библиотеки. Он может быть простейшим для начала: изменение переменной $ на 'lib', к примеру.
Вроде даже на Хабре было описание от azproduction (верно ник написал? :) ).
С примерами, со структурой.
С примерами, со структурой.
UFO just landed and posted this here
ОМГ. И этот человек ратует за чистоту великого и могучего.
Вы, очевидно, тролль. Но тем, кто действительно не сталкивался раньше с этим термином («актор»), нужно понимать, что UML-нотация — она устоявшаяся, все определения уже употребляются в проф. среде.
Если же переводить actor на русский в данном контексте, то это будет что-то типа «движитель», «субъект», но никак не «актер».
Если же переводить actor на русский в данном контексте, то это будет что-то типа «движитель», «субъект», но никак не «актер».
Sign up to leave a comment.
Три подхода к методологии построения сложного клиентского приложения