Как делать ветвление структуры в MVC?

[s8000_1]

Сообщение от __etc

1) Это каким образом изменение модели прошло в обход контроллера? Контроллер, если и слушает изменение модели, то только лишь те изменения, которые требуют добавления/удаления вьюверов. В противном случае, изменения отслеживаются исключительно вьюверами. Ну а если подходить к возможным замкнутым рекурсиям, то в любом случае (в любом, это важно), в сеттере должна стоять проверка на текущее значение, типа if (this._somevalue === value) return;.

Я про случай делегирования, когда во вьювере нет функции апдейта:

//контроллер
ns = new NumericStepper();
ns.addEventListener(Event.CHANGE, updateModel);
model.addEventListener(Event.CHANGE, updateViewers);
 
function updateViewers():void{
 ns.value = model.value;
}
 
function updateModel():void{
 model.value = ns.value;
}

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

Или все же надо сделать класс, наследующийся от NumericStepper, и убирающий этот "самоапдейт" из него?

Логика подсказывает, что проще вызвать сеттер вхолостую (с проверкой который), чем все делать идеально "правильно" переписав кучу стандартных компонент под "идеологию MVC".

[r_r_f_r]

Уиконтролы это чистые вьюверы, а если очень хочется в контроллер задать теже width, height то их стоит скромно делегировать, хотя нужно ли оно, это ещё вопрос.

[s8000_1]

Сообщение от r_r_f_r

Уиконтролы это чистые вьюверы

Я не сказал бы так, потому что у всех UIComponent "величина_которую_надо_апдейтить_извне" - это та же самая "величина_которая_апдейтится_изнутри". Контроллер следит за первой и апдейтит модель, вьювер подписан на апдейты модели и изменяет вторую величину.

[etc]

Сообщение от BlooDHounD

__etc, ну зачем категорично? это комбо-система ... пример: любой уиконтрол

А я не считаю логику в уиконтролах контроллерами

Сообщение от s8000_1

Я про случай делегирования, когда во вьювере нет функции апдейта:

А должна быть. В контроллере быть не должно.

Сообщение от s8000_1

Логика подсказывает, что проще вызвать сеттер вхолостую (с проверкой который), чем все делать идеально "правильно" переписав кучу стандартных компонент под "идеологию MVC".

Проверка в сеттере по определению должна быть, а «холостые» вызовы — неизбежны в MVC.

Сообщение от s8000_1

потому что у всех UIComponent

А в UIComponent, написанных как попало, много ещё чего не так.

[r_r_f_r]

Сообщение от s8000_1

Я не сказал бы так, потому что у всех UIComponent "величина_которую_надо_апдейтить_извне" - это та же самая "величина_которая_апдейтится_изнутри". Контроллер следит за первой и апдейтит модель, вьювер подписан на апдейты модели и изменяет вторую величину.

да в них есть какое-то подобие котроллера, но если не брать в рассмотрение сложные компоненты(грид и ...), контроллера там просто нет, есть стартовый UIComponent который и делает всю работу за них, это компоненты, а не mvc структура.

[†‡Paladin‡†]

Чето я невкурил что мешает сделать компонент по mvc модели. Пускай он там имеет собственный модель вид и контроллер, главное-чтобы это не касалось никого кроме него. Или я вообще не в тему?

[r_r_f_r]

Законченная mvc подразумевает присутствие модели, а что за компонент такой в котором модель находится внутри.

Второй пункт, пусть компонент имеет собственный контроллер, вид и модель, но тогда появляется вопрос кого добавлять на сцену, по идеологии только контроллер имеет ссылки на всех, т.е. нужно добавлять на сцену его, но он также не может быть отображаемым объектом, ..., это идеальная модель которая если и реализовывается то начиная с самого Document Class'a, в других же случаях мы пишем как раз то что предоставляет нам adobe.

[etc]

Компонент — это набор контролов (например, окно), а не один контрол, как называют в Adobe. Менеджер компонентов их создает и добавляет на сцену. Компонент при создании сам может создать контроллер со ссылкой на себя, дальше работает контроллер.

[r_r_f_r]

Сообщение от __etc

Компонент при создании сам может создать контроллер со ссылкой на себя, дальше работает контроллер.

Подразумеваешь делегирование создания всей структуры Display Object обёртке?

[†‡Paladin‡†]

Сообщение от r_r_f_r

Законченная mvc подразумевает присутствие модели, а что за компонент такой в котором модель находится внутри.

Второй пункт, пусть компонент имеет собственный контроллер, вид и модель, но тогда появляется вопрос кого добавлять на сцену, по идеологии только контроллер имеет ссылки на всех, т.е. нужно добавлять на сцену его, но он также не может быть отображаемым объектом, ..., это идеальная модель которая если и реализовывается то начиная с самого Document Class'a, в других же случаях мы пишем как раз то что предоставляет нам adobe.

Чем стандартное свойство data UIComponent`а не тянет на модель?
Почему нельзя создать внутри контроллер, управляющий моделью?
И почему обычный drawRect не может служить видом? Все можно запихать в 1 класс и наслаждаться работой, не подозревая о реализации.