Комментарии 27
> В модели Закаса бизнес логика и UI реализуется в песочнице и отчасти в ядре.
Разве?
Насколько я знаю, всё (UI и бизнес-логика) содержится в модулях, ядро и песочница служат только для оперирования модулями (создание/отключение, event managment, работа с правами доступа).
Песочница служит только одной глобальной цели — идентификация модуля, а это в свою очередь нужно для разграничения прав доступа.
Разве?
Насколько я знаю, всё (UI и бизнес-логика) содержится в модулях, ядро и песочница служат только для оперирования модулями (создание/отключение, event managment, работа с правами доступа).
Песочница служит только одной глобальной цели — идентификация модуля, а это в свою очередь нужно для разграничения прав доступа.
0
Да, вопрос хороший. Если помещать всё в модули, то модель Закаса почти сведется к MVC, где песочница — другое название Контроллера. Мне кажется, есть некоторая логика, которая неизбежно будет в ядре, а именно, когда перерисовка интерфейса фиксирует несколько модулей. Хотя я могу ошибаться.
Текст поправлю позже, когда наступит более четкое понимание.
Текст поправлю позже, когда наступит более четкое понимание.
0
Не согласен.
Модуль в данном случае содержит и 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к строк написано :)
+1
> В MVC логика зашита в Контроллере.
Имхо логика должна быть в модели
Имхо логика должна быть в модели
0
Есть ли где-то более подробное описание реализации модели Закаса, желательно словами, а не видео? А то приходится догадываться о том, как он представляет перенос данных и команд между уровнями и сколько дополнительных прикладных языков существует в его системе, чтобы в конце осуществились слова "основываться на любой из стандартных библиотек типа jQuery и менять их без проблем". Иначе звучит очень рекламно, потому что библиотека — это язык выражения действий. Смена библиотеки — смена языка. А, простите, на чём тогда выражена модель? Очевидно, на своём языке, со своими понятиями. И «беспроблемная» смена библиотеки означает «всего лишь» замену методов одной библиотеки методами другой. Или дописывание своего «контроллера» библиотеки — транслятора языка данной библиотеки в свой. Хочется увидеть, где об этом говорится.
+2
Согласен, мне тоже это показалось какой-то ересью. Вот использовал я MooTools, расширенные прототипы, его работу с DOM и всё остальное, а потом решил перейти на jQuery. Как это можно сделать легко? О, о
0
Легко не получиться. Смысл в том, что в ядре создается дополнительный уровень абстракции для управления методами библиотеки и плагинов. Поэтому при смене библиотеки или плагина достаточно переписать только ядро и не менять модули. Например, как-нибудь так
var Core = {};
Core.getElements = function( selector, context ){ return jQuery(selector, context||document); }//jQuery
Core.getElements = function( selector, context ){ return $(context||document).getElements(selector); }//Mootools
0
но ведь интерфейс у вернувшихся объектов разный
0
В этом и состоит задача ядра создать новый интерфейс для подключаемых библиотек. Насколько будет поменять библиотеку я себе слабо представляю. Это, как говориться, всего лишь идея. Знаю, точно, что в ядре очень хорошо оперировать со сторонними плагинами и менять их при необходимости.
0
а если декорировать возвращаемые объекты на уровне ядра?
0
И довольно трудно представить (точнее, не представляю), как транслируется представление (View) у него в Песочницу, а потом обратно, в требуемое представление. Вот, для примера. Есть у нас страница. Там разные блоки, стили, места для информации и для работы виджетов, и эти места пересекаются. Скажем, один виджет — показ кода, другой — подсветка кода в одном и том же блоке. Предлагается создать Песочницу, где тот же блок предстанет для первого скрипта как контейнер для текста, а для второго — как место для раскраски? Но ведь ясно же, что их действия пресекаются, какая здесь независимость? Ладно, по правилам Песочницы блок заполнили, раскрасили и ядро приложения переносит его обратно, в HTML. Можно представить себе, насколько тщательно ядро должно учитывать сособенности браузеров, чтобы отразить представление в Песочнице, а потом перенести обратно. (Я правильно понимаю модель поведения ядра?) И затем смотрим на результат и думаем, какие и на каком уровне допущены ошибки, почему и где у нас не получилось, как задумано. Вместо 2 предметов — виджет и объект — имеем Вид, Ядро, Песочница, Виджет (Модуль в его терминах). И ещё библиотека, с помощью которой написан Модуль — легко меняется. Значит, ещё имеем где-то в схеме Транслятор библиотеки в некий внутренний язык. 5 сущностей вместо 2. Так писать действительно легче?
0
Представление (VIEW) не содержится в схеме Закаса. Транслятор в ядре (в каком-то смысле ядро и есть транслятор, хотя предполагаются еще служебные функции).
Действительно ли писать легче — я на это не могу ответить. Кстати, Вы использовали MVC или MVVM в js?
Действительно ли писать легче — я на это не могу ответить. Кстати, Вы использовали MVC или MVVM в js?
0
Я писал на knockout в стиле MVVM.
А отсутствие слоя View я у него уже «исправил» (т.е. поставил туда, где оно могло бы стоять, правда, линия должна идти из ядра) и хочу предложить картинку немного по теме того, что обсуждается. И чуть ниже — почему я к ней пришёл.
Итак, есть ещё один путь построения архитектуры, я с ним познакомился не так давно, благодаря публикациям такой библиотеки: habrahabr.ru/blogs/javascript/133328/. Чтобы долго не искали суть, расскажу в 2 словах. Библиотека DOM-shim подходит к работе как с DOM, так и с моделью языка так, что создаёт мета-модель языка, близкую к новейшим стандартам, а остальные браузеры (практически все) подтягивает до понимания этой модели. И даёт работать в этой модели. Для самых далёких от модели браузеров ситуация будет выглядеть так, как на рисунке: они будут понимать задачу в песочнице, но транслятор не сможет её отобразить. И, как следствие, просьба заменить себя :).
В плане построения архитектуры — почему бы не взять за основу метаязык, близкий к стандартам?
А отсутствие слоя View я у него уже «исправил» (т.е. поставил туда, где оно могло бы стоять, правда, линия должна идти из ядра) и хочу предложить картинку немного по теме того, что обсуждается. И чуть ниже — почему я к ней пришёл.
Итак, есть ещё один путь построения архитектуры, я с ним познакомился не так давно, благодаря публикациям такой библиотеки: habrahabr.ru/blogs/javascript/133328/. Чтобы долго не искали суть, расскажу в 2 словах. Библиотека DOM-shim подходит к работе как с DOM, так и с моделью языка так, что создаёт мета-модель языка, близкую к новейшим стандартам, а остальные браузеры (практически все) подтягивает до понимания этой модели. И даёт работать в этой модели. Для самых далёких от модели браузеров ситуация будет выглядеть так, как на рисунке: они будут понимать задачу в песочнице, но транслятор не сможет её отобразить. И, как следствие, просьба заменить себя :).
В плане построения архитектуры — почему бы не взять за основу метаязык, близкий к стандартам?
0
Мне кажется, Вы немного ушли в частности. DOM-shim можно мыслить как плагин или как часть основной библиотеки. Аналогично Sizzle есть часть jQuery, и незачем выделять это в отдельный View. В основной библиотеке должна быть работа с сетью (XHR), работа с браузерными событиями и проч. техника — не будем же мы для каждого такого блока выделять отдельную логическую базу на схеме?
0
Да, часть основной библиотеки, тот самый необходимый метаязык. Точнее, заплатки, позволяющие реализовывать его во всех браузерах. (Можно считать язык абстрактным, но тогда смена языка изложения потребует переписывания всех программ.) У меня и был об этом вопрос — каков язык описания на клиентской стороне? Взятие его за основу позволит написать ядро и отвязаться от других библиотек.
-1
Есть скринкаст-курс marketplace.tutsplus.com/item/writing-modular-javascript/128103/, платный.
Но я его пока не смотрел. Пока что я тоже понял Закаса в том смысле, что есть некоторый транслятор для стандартной библиотеки. Он может быть простейшим для начала: изменение переменной $ на 'lib', к примеру.
Но я его пока не смотрел. Пока что я тоже понял Закаса в том смысле, что есть некоторый транслятор для стандартной библиотеки. Он может быть простейшим для начала: изменение переменной $ на 'lib', к примеру.
0
Вроде даже на Хабре было описание от azproduction (верно ник написал? :) ).
С примерами, со структурой.
С примерами, со структурой.
0
НЛО прилетело и опубликовало эту надпись здесь
ОМГ. И этот человек ратует за чистоту великого и могучего.
+2
Вы, очевидно, тролль. Но тем, кто действительно не сталкивался раньше с этим термином («актор»), нужно понимать, что UML-нотация — она устоявшаяся, все определения уже употребляются в проф. среде.
Если же переводить actor на русский в данном контексте, то это будет что-то типа «движитель», «субъект», но никак не «актер».
Если же переводить actor на русский в данном контексте, то это будет что-то типа «движитель», «субъект», но никак не «актер».
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Три подхода к методологии построения сложного клиентского приложения