[Panzermaus]

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

Т.е. много моделей, много видов и один контроллер

Да.

и нету соответствия между видами и моделями?

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

Т.е. у тебя виды как реализованы? Один класс? Или разбиты по принципы input/output, один класс изменяет DOM, второй реагирует на события?

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

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

Все верно.

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

Но это не MVC и я не вижу причин разбивать этот автокомплит на модель-вид-контроллер. А вы?

Подойдем к примеру чисто схоластически

Какие бывают автокомплиты? Получающие данные через ajax, или через масив [1]; показывающие все варианты со скроллом или ограниченное количество без скролла [2]; ищущие только по началу, ищущие во всем значении [3].

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

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

ваши предложения?

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