расширяемость обратно-пропорциональна легкости в поддержке. Возьмем автокомплит. Какие бывают автокомплиты? Получающие данные через ajax, или через массив; показывающие все варианты со скроллом или ограниченное количество без скролла; ищущие только по началу, ищущие во всем значении. Думаю, можно еще что-нибудь придумать, но остановимся. Какое должно быть расширяемое решение?

var AutoComplete = new Class({
    initialize: function( ArraySource|AjaxSource dataSource, CompleteList|BriefList list ){...}
    ...
});

var ArraySource = new Class({
    initialize: function( StartingWithStrategy|SearchAnywhereStrategy searchStrategy ){...}
    ...
});

var AjaxSource = new Class({
    initialize: function( StartingWithStrategy|SearchAnywhereStrategy searchStrategy ){...}
    ...
});

Итого, семь классов. Что мы получили? Правильно, Hello, world! in patterns. И оно так же не легко в поддержке, как и в использовании. Да можно сделать это не таким расширяемым и оно станет проще. Но это не MVC и я не вижу причин разбивать этот автокомплит на модель-вид-контроллер. А вы?

т.е. не библиотеку, а фреймворк. Посоветую не ограничивать пользователя (MVC/неMVC, события/несобытия). Просто предоставь пользователю удобные средства для реализации разных способов взаимодействия, реализации модулей

ты себе противоречишь, или шаблон будет преобразовываться в конкретную разметку на каждом конкретном сайте? А что с css/js. Ведь они с DOM работать будут, т.е. должны зависеть от этой конкретной разметки. Или тоже будут преобразовываться/работать через промежуточный слой?

кроме того, ты уверен, что у тебя MVC, а не HtmlCssJs? Ведь можно сказать, для того же select, что модель там - пункты списка и какой из них текущий, вид - html+css, контроллер - js

звучит как маркетинговый ход:
- Посмотрите, как просто в нашей программе сделать вот ЭТО!
- Вау, прикольно, а как насчет вот такого?
- А... Э... Ну, я вам потом расскажу... если захотите :)
(ну это так, подумалось)

da_ff (и не только), не обязательно подробно рассказывать реализацию. Просто пример привести. Например, связанные списки. Они не могут просто реагировать на изменение любого другого списка, потому что я добавлю третий список и обновляющийся список будет реагировать на события от двух списков. Т.е. должен быть какой-то код, специфичный для формы, который связывает списки. Надо сделать так?

<pr:list id="list1"></pr:list>
<pr:list link-with="list1"></pr:list>

И чем это отличается от

var list1 = new List();
new List({'link-with': list1});

просто другая форма записи
Хотите Mediator? Пожалуйста, надо только дважды расширить list, придумать для них какое-то свое событие, один его будет отправлять, а второй слушать

<pr:list-1></pr:list>
<pr:list-linked-with-list-1></pr:list>

ваши варианты?

Panzermaus, интересно, т.е. у тебя полный MVC один большой MVC? Т.е. много моделей, много видов и один контроллер и нету соответствия между видами и моделями? Ну да, раз должно быть undo/redo, должен быть какой-то координатор. Да и взаимодействие там, наверное, сложное, так что наличие координатора вдвойне имеет смысл. Но я говорил про нечто не такое высокоуровневое. Т.е. у тебя виды как реализованы? Один класс? Или разбиты по принципы input/output, один класс изменяет DOM, второй реагирует на события? Или как удобно в каждом конкретном случае?
И еще, я правильно понял, что виды не принимают уведомления напрямую от модели и контроллер не уведомляет виды о каждом отдельном изменении, потому что некоторое действие вызывает цепь изменений, а контроллер дожидается пока это все завершится и сообщает видам, что изменилось пакетом, а не про каждое изменение по отдельности?

Отпуск. Продержался без компьютера целых четыре дня! :)

Да.

Нету: одно V одновременно отображает множество объектов M; один и тот же объект M отображается одновременно несколькими Vs.

Каждый V - один класс-синглтон, который работает со своими элементами DOM и обрабатывает все события этих элементов. Деления input/output нет.

Все верно.

ИМХО, MVC не задумывался как эталон модульности и не является им (а в моем исполнении и подавно). MVC - это не ослабление связности, а ее сознательное перераспределение, если можно так выразится. Сознательно исключаются зависимости M от С и от Vs, а также Vs друг от друга, в то время как зависимости С от M, Vs от M, Vs от С остаются. Таким образом, только M можно считать модулем - ее можно перенести в другое приложение без переделок, и при этом она за собой не потянет других компонентов. C же тянет за собой M, а V - и M, и C (лично я ослаблять эти зависимости и не старался, поэтому компоненты общаются через интерфейсы, а не через события/подписку). Короче, MVC решает задачу модульности лишь отчасти.

Подойдем к примеру чисто схоластически :)
[1] и [3] - ответственность модели, а [2] - ответственность представления. Применение MVC (отделение M) оправдано, если M используется по-разному и/или в разных местах, то есть когда существуют другие V/C, кроме инпута с выпадающим списком. Например, когда юзер ограничен имеющимися в списке значениями, а набирает что-то левое, то ему предлагается тот же список, но уже в виде ссылок (возможно, вы имели в виду...). Или вместо списка - карта города с флажками, и по мере ввода названия фирмы/рубрики этих флажков становится меньше. Если никаких подобных V нет, то единственное оправдание для использования MVC - это то, что M уже отделена от V/C. Например, по привычке :)

Если бы модульность была требованием, то я бы сделал так: допустим, есть три списка - страны, города (связанный со странами) и пол (не связанный с предыдущими). Есть диспетчер модулей/событий. Каждый модуль-список является источником соответствующего события: CountryChange, CityChange, GenderChange. Второй список подписан на CountryChange, чтобы отфильтровывать свои строки. А на CityChange и GenderChange подписана, например, кнопка submit, чтобы делаться enabled. (Она же может быть подписана на BirthdayChange и CaptchaGuessed, причем последнее событие генерируется сервером.) Что дает такая схема? Например, можно продублировать список стран картой мира. И список стран, и карта генерируют одно и то же событие CountryChange. Тут, правда, есть нюанс: генератор некоторого события должен автоматически становится и подписчиком этого события, чтобы список и карта были синхронизированы. Кроме того, можно подменить каптчу-рисунок на арифметический пример, два инпута плюс список - на полноценный календарь, и даже убрать либо список стран, либо карту. Функционирование оставшихся модулей не изменится.

Panzermaus, ну что ж, похоже мы во мнениях сходимся :) Добавлю только немного

не задумывался, и когда его так воспринимают, не могу сдержаться...

я бы сказал, что если компонент становиться большим, его нужно рефакторить, у него слишком много обязанностей. Т.е. высокая связность со временем может уменьшаться. И это не обязательно разбиение на несколько классов, составляющих компонент. Можно как вариант вынести какую-нибудь библиотечную функциональность (например, управление курсором в input type="text"), или создать промежуточный компонент (расширенный input type="text"). И MVC это один из вариантов решения проблемы, причем вид и контроллер обычно cильно связаны, т.е. разделять имеет смысл как-то так M/VC, если у модели не один вид/контроллер или нету однозначного соответствия. V+C если и разбивать, то по каким-то другим критериям. Все это, естественно, в контексте разработки клиентской части веб-приложения. Кстати, твой глобальный контроллер... я бы его все-таки каким-нибудь координатором/диспетчером назвал

ну это пожалуй редкое обоснование

потому что у тебя конкретные компоненты для конкретной страницы. Для более общих компонентов исходящие события бы как раз пригодились, только связывать их не обязатльно через какой-то третий класс (Mediator)

ну это по сути мой второй вариант. А по поводу событий, это по определению более сложный вариант взаимодействия. Когда мы видим вызов метода, мы знаем, что объект-назначение один, в случае события это уже не очевидно. Кроме того, в сложных случаях может выясниться, что некоторое событие возникает не очень во время и надо как-то переделать эту схему взаимодействия. В результате мы повысили реюзабельность за счет более сложного взаимодействия и большего количества компонентов (список/зависимый список), либо просто усложнили взаимодействие

p.s. кстати, B~Vladi, советую исходить из практики, типа сделал ряд приложений по определенной схеме и получил фреймворк в качестве бонуса. Чтобы чувствовать эффект от принятых решений. Если это, конечно, не так

x-yuri, с MVC пришли к консенсусу :) Даже по вопросу M/V/C vs. M/VC, что вдвойне приятно. Это на серверной стороне отдельные V/С уместны, так как там input и output естественным образом разделяются.

Согласен, надо назвать этот паттерн Model-View-Dispatcher aka MVD :)

Разница есть. Это не list2 = new List({'linked-with': list1}), а скорее list2evt = new List({'filter-when': 'event1'}). Кто является источником event1, сколько тех источников (и есть ли они) для list2evt все равно.

Да, это цена за определенные преимущества, которая может быть как чрезмерной, так и вполне приемлемой, в зависимости от ситуации.

Снова-таки в зависимости от конкретной ситуации, это может быть и недостатком, и достоинством. Пример: получателями события CountryChanged могут быть не только cityList, но и imgFlag, yourRegionalDealerContacts, да и мало ли что еще.

А вот это чегтовски серьезное возражение! Поскольку ни одного законченного event-driven фреймфорка я не написал, то со скользкими случаями мог попросту не сталкиваться. Правда есть подозрение, что в действительно сложном случае взаимодействие через интерфейсы тоже хлебнет горя :) Пример бы...

В случае двух списков так и выходит: было 2 компонента и 1 зависимость, стало 3 компонента (+диспетчер) и 2 зависимости. Но допустим, взаимодействующих компонентов 10. Между ними может быть от 9 до 90 зависимостей - это и есть "конкретная ситуация". И это еще не все: зависимости могут быть очень разнообразны, например, если компоненты A, B, C зависят от X, и X потребовалось заменить на Y с другим интерфейсом, то A, B, C нужно будет подвергнуть переделке неизвестно какой глубины - от названий методов до всей логики.

А при взаимодействии через события количество компонентов хотя и увеличивается до 11, но зависимостей будет строго 10, причем зависимости исключительно однообразны и просты (подразумевается, что интерфейс диспетчера стабилен.)

да и по поводу событий тоже сходимся во мнениях. Я может разве что больше делал упор на недостатки событий. Потому что ТС их как-то слишком превозносит. Т.е. уведомления от компонентов это хорошо, тем более что речь идет о библиотечных компонентах. Но компоненты, рассчитанные реагировать на события... я такого еще не видел, или не припоминаю. Во-первых, это навязывает наличие Mediator'а. Но даже если он предоставляется фреймворком, думаю, такой подход не всегда подойдет, скорее для простых случаев. А так, да, события бывают уместны, а бывают не уместны...

помню когда-то пытался кастомизировать TextBox в Delphi, перехватывал события от клавиатуры, но так и не добился, чтобы оно работало как надо. Но может они либо на это не рассчитывали, либо неудачно как-то организовали все это дело. Там правда, наверняка, использовался стандартный элемент управления Windows, так что все еще сложнее. Но это так, вспомнилось, да и деталей уже не помню

Или есть допустим схема с какими-то компонентами и модель. Модель обновляется и сообщает об этом компонентам. И тут я понимаю, что для какого-то компонента, нужно предыдущее состояние знать, а модель-то уже изменилась. Ну я сначала сделал еще одно событие beforeUpdate. А потом просто решил запоминать в компонентах нужную информацию (типа локальная модель). Ну т.е. можно считать, что совместил модель и компоненты, соотношение один-к-одному, так что нормально. Правда я к тому же до этого считал, что модель в DOM хранить можно (типа по состоянию DOM все нормально выясняется). Зачем еще дублировать в javascript-объекте? Оказалось лучше дублировать. Так вот в результате я получил более простое и понятное решение, чем с "большим MVC" и большим количеством событий

Вам нужно работать в одной команде.

Давайте ещё немного поговорим :)
Начну с описания того, что у нас есть, а потом уже решим что с этим делать. А есть у нас тупо:
1. HTML в связке с CSS.
2. JS-код. Все-таки мы пишем приложение.

Дальше я просто расскажу ход своих мыслей, посещающих меня во время создания архитектуры моего проекта.

Так, есть куча функционала в ТЗ. Если я все это дело раскидаю на отдельные логические составляющие, мне будет проще ориентироваться по всему проекту, а значит и поддерживать его. Сначала я опишу каждую составляющую более абстрактно, без привязке к отображению или к чему либо ещё, на какой-нибудь тестовой страничке. В такой среде код сам будет писаться как самостоятельный модуль. Аха, мы получили первый модуль. Получили второй. Третий. Внутри у них четко определённый функционал, раскиданный по нужным полочкам. О внутреннем устройстве вскоре можно будет забыть, но сначала нужно определить способ воздействия на внешний мир. API может вытащить наружу? Нет, связывать модули мы не будем. Может медиатор? Может. Наблюдатель? Тоже вариант не плохой.

А может нам объявить модули как модели, разметку как вид и реализовать для всего этого контроллер, превратив функционал всего проекта в одну классическую MVC-архитектуру? Хм... Это бы решило проблему с взаимодействием модулей... Но как? О, точно, у нас для этих целей уже давно придуман патерн Observer. Хорошо, он поможет нам реализовать синхронное взаимодействие контроллер <-> модель. Так. А что там у нас с видами? Задача контроллера - обновлять виды при изменениях состояний моделей. Прикроем-ка мы разметку классом вида и упростим общение с контроллером посредством, например, патерна Команда или того же API. Хм. В таком случае контроллер должен знать от кого в какой вид что посылать и поэтому может разрастись - моделей/видов-то много. Что-то больно тяжелый микс патернов получается, но вполне рабочий. Надо реализовать.

Что мы ещё можем придумать? А можем сделать все намного проще, как я уже намекал выше... Есть наша куча модулей... Реализуем общение между ними при помощи медиатора или наблюдателя, а о разметке забудем навсегда. Тогда, для качественной разработки модулей необходимо разделять их внутреннее устройство на составляющие, например на M, V и C. Решение рабочее, будем реализовывать.

Что получили в итоге. Самое интересное для нас - это модули. Мозг и логика всего приложения. Каждый кусок этого мозга влияет на все приложение в целом, а значит должно эффективно решать свои задачи. В первой реализации мы получили чистый функционал в коде модулей, без примесей. Во втором варианте же каждый сам за себя - плевать на все приложение в целом. Но не будет ли чистота первого варианта испорчена реализациями остальных компонентов - C и V?

Вот это я и хочу проверить. Как что-то будет готовое - отпишу.

ты нечетко выражаешь свои мысли, поэтому я и говорю, что лучше обсуждать на конкртном примере

Что не понятно то?! Будет пример, погоди.

читаю, вроде примерно понятно, но потом натыкаюсь на какую-то фразу и ломаю об нее голову... дай-ка попробую продемонстрировать

в общем целостная картина не складывается и даже спрашивать сложно, разве что по одному вопросу, иначе следующие вопросы надо задавать основываясь на предположениях

и в целом вроде похоже, что первый вариант - то, о чем я говорил, а второй вариант - твой. Так вот я не о том говорил, если что

p.s. на всякий случай напомню, что вопроса в по сути два: как связывать компоненты и to MVC или не to MVC

Ну в общем то да. Для решения их конечно же надо писать код, а не рассуждать постоянно.
Ну да, вообще описание классов, внутреннего функционала. Без каких-то конкретных действий.
Воздействие на отображение и на другие модули. Как вариант - генерация событий.
Ну вот и я о том же.
Да. По-сути он и будет фреймворком.
Я понимаю что это, но рассказать навряд ли получиться:)
Ой, я имел ввиду двухстороннее. Любой может генерировать события.
Ну он хорошо подходит на это место. Контроллер будет командовать. Реализация не сложная. Конечно, я готов рассмотреть другие варианты.
т.е. ты предлагаешь пробрасывать события V <-> C <-> M ?!
Имеется ввиду, что фреймворк никак не будет изменять разметку (отображение), а будет только инициализировать/связывать модули.
А так как фреймворк не работает с разметкой, эта задача перекладывается на модули.
В том, что модуль реализует только бизнес-логику. Мало кода, все красиво и понятно оформлено (ну если руки не из жопы).
Да, так же связаны.
:)
Нет, просто так показалось. Посмотрим что выйдет.