Зато в моём видении брать посчитанные значения css для элемента не просто некрасиво, а неправильно. :)

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

кстати, jQuery - не первый вариант, плагины не зависят друг от друга

причин использовать MVC нету, хорошо

это теоретически рассуждения или ты видишь какую-нибудь конкретную ситуацию?

я говорил о взаимодействии компонентов (компонент = M+V+C) между собой. И надо было зачеркнуть что ли эту фразу. Давайте говорить на каких-то конкретных примерах, а то все так абстрактно, что можно что угодно сказать. Например, "псевдоселект"... Он сам по себе ни с кем не связан. Но если на какой-то странице нам его надо связать, т.е. заставить конкретный экземпляр компонента делать что-то специфичное для данной страницы:

new Select({
    'change': function(){
        $('#my-form').submit();
    }
})

поищи. Еще можно здесь почитать, тоже на англ. В конце концов есть google-переводчик. А вообще, английский - lingua franca как никак

и я о том же, просто привычка. А ведь MVC создавался в совсем другой среде и основная задача задача была отделить представление от данных, чтобы можно было иметь несколько представлений данных. А разделение на input/output непонятно зачем было сделано (может потому что я на Smalltalk не программировал, какие-то там особенности). Так почему мы не создаем две параллельных иерархии объектов (виды и контроллеры), как это было в Smalltalk? Где о событиях уведомляется самый верхний контроллер и передает это событие по дереву нужному элементу, над которым сейчас мышка, спрашивая у видов "Мышка над тобой?". Наверное, потому что эта часть уже реализована и реализована по-другому, надо просто повести обработчик события на нужный DOM-элемент. Но тем не менее мы продолжаем делить на модель, представление, контроллер. Несомненно, в каких-то случаях это удобно. Но не слишком ли часто он применяется? Тем более что с тех пор было много разных вариаций/трактовок/реализаций. Если контроллер будет практически пустой, а вид будет занимать несколько тысяч строк, мы так и будем считать, что такое разбиение правомерно? Или в этом случае все-таки подумаем, что разбивать на классы/распределять обязанности можно по-разному?

не зависит, ну и что? Но вид/контроллер может отображать какую-нибудь сводную таблицу на основе нескольких источников

во-первых, у меня по-разному выходит. Может у тебя привычка сказывается? ;)
во-вторых, активная модель (в изначальной реализации MVC была и пассивная) как раз и должна уведомлять тех, кто на это подписался, об изменениях. Если же модель изменяется только одним контроллером, она может быть пассивной (контроллер сам знает, когда изменилась модель и сообщает об этом виду). И активная модель как раз таки не знает, сколько у нее представлений, как и пассивная впрочем.
Зачем может понадобиться так разделение? Например readonly-контроллер, но это какая-то такая экзотика, имхо

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

и еще, ведь редко нужно иметь несколько видов для одних и тех же данных? Мне пока в голову пришли только разные варианты отображения файлов в Проводнике. Так вот когда это надо, можно делить, я считаю. Т.е. причина для именно такого деления есть (M/VC)

а можешь подробнее?

Несколько приложений работают на своем объекте диспетчеризации. в общих чертах для этого требуется чтобы каждый модуль мог делегировать через сторонний диспетчер хотябы два метода bind и unbind. По опыту могу сказать то, что использует механизм диспетчеризации поддерживается удобнее. Так же большим плюсом становится возмонжость разделить модули по файлам, которые работают только со своими данными не обращаясь к сторонним объектам определенным в других модуля.

da_ff, можешь подробнее рассказать? Модули могут подписываться на события от конкретного источника или любого? Можешь какой-нибудь конкретный пример взаимодействия модулей привести? Ты используешь MVC?

Сейчас это единственный вариант, подходящий по требованиям, который я вижу.
API вынуждает писать логику, которая зависит от плагинов.
Классическая ситуация - таб. Если он не активен, его содержимое незачем обновлять. Да мало ли на странице может быть скрытых блоков.
Да, я в курсе:)
Ок, нада что-нить - набросать.

Ох если выдирать куски из листингов толку будет мало. попробую написать крохотную демку.
Еще кстати для котроллера необходимо предусмотреть механизм передачи данных из объекта которые создает некое событие в его подписчиков.
Вообще мое имхо, что такая событийная модель более естественна для js. Поскольку большАя часть тех операций для которых он используется имеют ассинхронную природу.

озвучь требования что ли

jQuery вынуждает писать логику, которая зависит от плагинов. Но это не проблема. Проблема в том, что jQuery не предоставляет возможности создавать компоненты. Если же ты про взаимодействие через API, то взаимодействующие компоненты не обязательно будут зависеть друг от друга, можно просто создать какой-нибудь координирующий уровень, который не будет работать через события (Service Locator). Например, в случае с псевдоселектом, он мог спросить у этого координатора форму и отправить ее

services().get('form')->submit();

причем так даже лучше в данном случае, чем отправлять событие, потому что события это уведомления и они хороши, когда имеется сложная логика взаимодействия, когда заранее неизвестно, кого уведомлять. Но в общем-то так слишком сложно, потому что это код, специфичный для формы. Это что-то типа "не допущу, чтобы форма зависела сама от себя". Можно просто в обработчике события отправить форму, как я писал выше

обновлять? Возникает подозрение, что ты хочешь сделать что-то extjs-подобное или приложение типа gmail, т.е. которое обновляется. Озвучь свои цели

по поводу MVC, я вижу причину отделять модель от вида/контроллера, если нету четкого соответствия одна модель - один вид/контроллер. А вид с контроллером обычно слишком тесно связаны. Еще бывает смысл вынести код, который напрямую работает с DOM в отдельный класс, чтобы, если надо будет менять внешний вид, оно по-крайней мере не было перемешано с логикой работы. И в этом случае один класс (основной) - модель+контроллер, второй (работа с DOM) - контроллер+вид. По поводу первого из этих двух случаев есть смысл общаться через события, а именно уведомлять об изменениях модели

если взять WPF, например, там стандартные компоненты изначально никак не связываны. Стандартный способ их связать - в коде окна, т.е. в коде окна ты ловишь события от компонентов и изменяешь/управляешь другими компонентами. Т.е. что-то типа

new Select({ 
    'change': function(){ 
        $('#my-form').submit(); 
    } 
})

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

а то, что ты хочешь сделать, называется Mediator. Но для каждого паттерна есть, условия, при которых его имеет смысл применять. Он может использоваться в одной части приложения и не использоваться - в другой

я не говорю, что события - плохо. Я говорю, что кроме событий есть несобытия ;) И кстати, про асинхронность (обновление) B~Vladi только сейчас упомянул, по крайней мере явно. При обновлении информации на странице, конечно, без событий не обойдешься. А что будет происходить при получении ответа от сервера... случаи разные бывают :)

Уже:
В двух словах - пытаюсь реализовать клиентскую платформу, под которую затем будут писаться модули (плагины, виджеты - называйте как хотите). Именно не "удобное API", а интерфейс взаимодействия. Что посоветуешь?:)
Модули же эти должны реализовывать логику. Представление данных, отдаваемые ими, может быть совершенно разным (один модуль на 10 сайтах).
Сам модуль будет состоять из описания логики, представления и данных.

Т.е. получается и внутренне разделение (внутри модуля) и внешнее (то, что будет отражено в результате). Сложно так абстрактно говорить.

Пример структуры модуля:

<module prefix="pr" ns="urn:myModule">
  <template name="tpl">
    <!-- HTML -->
  </template>
  <status>
    tag {
      color:inherit;
    }
    tag.show:click {
      color:#f00;
    }
  </status>
  <code>/* JavaScript */</code>
</module>

Т.е. xml.

Здесь модуль имеет шаблоны данных. Сами данные он берёт из xHTML кода, например:

<pr:tag>data</pr:tag>

Т.е. при нахождении этого элемента в состоянии (классе) show и клике по нему, будет изменятся цвет. Причем для этого нужно всего лишь описать это в состоянии (тег status) и всё.

Не понял :( Сейчас расшифрую, что я имел в виду, а потом расшифруйте вы :)

Да, ты прав, это тоже причина отделять модель от остального. Со словом "сводную" стало понятно. А то я подумал, что один и тот же вид/контроллер отображают, например, сперва товар, а в следующий момент юзера :)

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

Начну :) Мой текущий проект (моя часть проекта) это что-то навроде автокада :) (Увы, не могу показывать недоделанный, не решаю таких вопросов :( Так что могу только рассказывать словами.) Короче редактор. Объектная модель типичного документа - связанные древовидно и как попало 100-300 объектов 15-ти разновидностей. У документа несколько представлений:

• интерактивный 2D чертеж;
• интерактивный псевдо-3D чертеж;
• труЪ 3D представление (пока еще конь не валялся :));
• небольшой read-only эскиз вроде Navigator-а в фотошопе;
• окно свойств выделенного объекта как боковая панель в 3dsmax;
• текстовое таблично-древовидное представление.

Пользователь может их скрывать/показывать как ему заблагорассудится.

Делаю в духе MVC. Так как между объектами M (их свойствами) и элементами HTM/SVG/VML DOM (их атрибутами) нет прямого соответствия, то M - это просто набор JS-объектов, никакой связи с DOM не имеющих. M извещает C об изменениях. C знает, какие Vs видимы (управляет этим), и извещает их. C мог бы извещать Vs и без напоминаний от M, так как он знает, когда M изменилась. Однако из за низкой производительности полные перерисовки Vs недопустимы, и нужно точно знать список изменившихся объектов, и поэтому требуется извещение от M. В этом смысле M активна, но она пассивна в том смысле, что Vs сами берут из нее укзанные данные (тоже из-за производительности). Vs привязывают к событиям DOM (click, change) обработчики, которые преобразуют их в события приложения ("команды": Select, PropertyChange), попадающие в C. C, если того требует команда, вызывает методы M. Не все команды исполняются на клиенте, некоторые требуют запросов к серверу. Всем обменом ведает C, кроме этого он поддерживает undo/redo-стэк, и еще кое какой сервис для Vs вроде панелей инструментов и справки.

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

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