Хорошее MVC

[Zebestov]

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

Хорошо. Предположим вы делаете не игру, а польз. интерфейс заносите ли вы координаты кнопок в модель?

Ну и на этот вопрос тебе Dukobpa3 уже давал ответ, с которым я согласен

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

Юнит — не кнопка. Юнит — фигурант логики приложения. Кнопка — кликабельный кусок монитора.

[fish_r]

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

Ну и на этот вопрос тебе Dukobpa3 уже давал ответ, с которым я согласен

Юнит — не кнопка. Юнит — фигурант логики приложения. Кнопка — кликабельный кусок монитора.

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

Добавлено через 1 минуту

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

Никогда не оценивал возраст по годам, сорри.

Блин, а как его ещё можно оценивать? Вы просто непрерывно открываете для меня "новые горизонты".

[Dukobpa3]

@Zebestov - Спасибо, наверное))) Мои слова поняты верно и с первого раза, плюс за поддержку.

@fish_r - Слушай что тебе старшие говорят ;-Р

[fish_r]

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

@fish_r - Слушай что тебе старшие говорят ;-Р

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

[HardCoder]

Интересует взаимосвязь модели с вью. Вьюшка не может изменять модель. Но у нее есть ссылка на модель, соответственно... сами понимаете что. Акцессоры здесь не подходят, так как контроллер должен изменять те же свойства, которые читает вью. В отдельный пакет вьюшку тоже не закинешь. Понятно, я не собираюсь в представлении как-то менять модель . Но интересно на будущее, просто чтобы уж "совсем правильно", как здесь быть?
Если создать событийный класс для событий модели (имею в виду "пользовательское событие" по К.Муку). В этот класс при диспатче из модели передавать все доступные параметры для вьюшки. Это будет правильно?

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

[Zebestov]

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

...при диспатче из модели передавать все доступные параметры для вьюшки. Это будет правильно?

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

[HardCoder]

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

Ей даже не важно, кто и каким образом поменял эти значения (модель сама там что-то насчитала, контроллер что-то там вызвал, с сервера данные подоспели).

Это понятно. Я же не говорю что она должна знать кто что менял.

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

Не правильно. Вьюшка просто услышит про изменения и сама пойдет к модели выяснять, что там поменялось.

Жаль что не правильно. Яхотел просто вьюшку подписать на события модели и больше модель в ней вообще не трогать. Что-то типа этого:

model.addEventListener(ModelEvent.UNIT_ACTIVATED, activateUnit);
private function activateUnit(e:ModelEvent):void {
      trace(e.activeUnit);
}

То есть, чтобы за свойством activeUnit не лезть в модель с которой по-пьяни можно сделать что-то, а получить его прямо из событийного обьекта ModelEvent.
Что же, будем делать "правильно". Спасибо

Добавлено через 8 минут

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

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

Не совсем понял. У меня какбэ все просто. Есть класс ModelEvent, на события которого подписываются две вьюшки, вернее одна вью - и компьютер(АI). Они получают такие события от модели. Отправляют в контроллер события OpponentEvent.

[Dukobpa3]

Вьюшка не может изменять модель. Но у нее есть ссылка на модель

да

Если создать событийный класс для событий модели

Как вариант прокатит, и даже более того это будет один из самых правильных вариантов но сложен в реализации. Сложно будет сделать адекватный рендер с обработкой всех событий и слишком легко запутаться.

Акцессоры здесь не подходят

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

Т.е. получается модель продиспатчила - меня изменили. Вью полезла посмотрела нужные данные и всё.

Добавлено через 3 минуты

Не правильно. Вьюшка просто услышит про изменения и сама пойдет к модели выяснять

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

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

Добавлено через 8 минут

Ей даже не важно, кто и каким образом поменял эти значения

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

[Dukobpa3]

model.addEventListener(ModelEvent.UNIT_ACTIVATED, activateUnit);
private function activateUnit(e:ModelEvent):void {
      trace(e.activeUnit);
}

Это только одно событие получается. Юнита активировали. А будет еще пачка, юнит походил, юнит атакует, юнит копает, юнит в доме.

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

[HardCoder]

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

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

То что я и хотел узнать!!!