Показать сообщение отдельно
  #32 (permalink)  
Старый 22.07.2010, 01:13
Аватар для x-yuri
Отправить личное сообщение для x-yuri Посмотреть профиль Найти все сообщения от x-yuri
 
Регистрация: 27.12.2008
Сообщений: 4,201

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

Сообщение от x-yuri
и почему обязательно MVC?
Сообщение от B~Vladi
Мне нравится такая идея, почему бы и нет?
причин использовать MVC нету, хорошо

Сообщение от x-yuri
а зачем нужны отложенные события?
Сообщение от B~Vladi
Оптимизация, например. Если визуально элемент скрыт, а обновление данных поступило в модуль, совсем не обязательно их применять. Возможно, они и не понадобятся пользователю, по крайней мере в момент обновления.
это теоретически рассуждения или ты видишь какую-нибудь конкретную ситуацию?

Сообщение от x-yuri
если это какие-то общие/повторно-используемые - лучше события
Сообщение от B~Vladi
Конечно, компоненты будут использоваться многократно, на любой странице любого сайта и изменения может вызвать любой из них (компонентов). Поэтому необходимо отделить их от данных и представления (html, css) как можно дальше.
я говорил о взаимодействии компонентов (компонент = M+V+C) между собой. И надо было зачеркнуть что ли эту фразу. Давайте говорить на каких-то конкретных примерах, а то все так абстрактно, что можно что угодно сказать. Например, "псевдоселект"... Он сам по себе ни с кем не связан. Но если на какой-то странице нам его надо связать, т.е. заставить конкретный экземпляр компонента делать что-то специфичное для данной страницы:
new Select({
    'change': function(){
        $('#my-form').submit();
    }
})


Сообщение от B~Vladi
Может на русском есть? А то я не осилю
поищи. Еще можно здесь почитать, тоже на англ. В конце концов есть google-переводчик. А вообще, английский - lingua franca как никак

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

Сообщение от Panzermaus
Зачем, например, отделять модель от вида/контроллера? Чтобы можно было их отобразить с помощью другого вида/контроллера, или чтобы вид/контроллер могли использовать данные из нескольких моделей.
Сообщение от Panzermaus
ИМХО, только первый вариант. Ведь отделение одностороннее: модель не зависит от контроллера/видов, а они зависят от модели по полной.
не зависит, ну и что? Но вид/контроллер может отображать какую-нибудь сводную таблицу на основе нескольких источников

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

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

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

Сообщение от subzey
Зато в моём видении брать посчитанные значения css для элемента не просто некрасиво, а неправильно.
а можешь подробнее?
Ответить с цитированием