Хорошее MVC

[etc]

Сообщение от Psycho Tiger

почему событийная модель DO для тебя не лучше.

Я где-то об этом сказал? Это для тебя она не лучше.

[Psycho Tiger]

Блин.

Если есть мысли, как это можно сделать лучше - то почему это плохо?

Лучше != удобнее. Скопировать событийную модель displayobject-ов — это удобно. Даже если она будет медленнее, чем варианты с прямым вызовом.

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

[etc]

Пост #97

[Psycho Tiger]

Ок, не так друг друга поняли.
Ты используешь нативный EventDispatcher, а в случае нужды бабблинга просто редиспатчишь в "родителе"? Или используешь DO, как dimarik?

[etc]

Сообщение от Psycho Tiger

Ок, не так друг друга поняли.
Ты используешь нативный EventDispatcher, а в случае нужды бабблинга просто редиспатчишь в "родителе"? Или используешь DO, как dimarik?

Первое.

[Psycho Tiger]

Понятно, спасибо.

[Zebestov]

Сразу говорю: MVC — только разбираюсь, UML — вообще никогда не ругайте.
Вот набросал схемку:

[IMG]http://s39.***********/i086/1009/9b/39f0a12eb88f.jpg[/IMG]

Допустим решил я сделать Menubar.

Model хранит массив кнопок (id, title)

View рисует все кнопки, что есть в Model, по событию CHANGE.

Controller запрашивает у API сервера (через другой контроллер — APIController) список доступных пользователю кнопок, парсит ответ и записывает в модель уже в виде требуемого массива. Также по нажатию на кнопку контроллер получает id кнопки и предпринимает определенные действия.

Обращение к API происходит вызовом метода APIController#request(req:String):APILoader, т.е. мы подаем запрос в неком универсальном формате (например синтаксис Facebook Graph API нравится), метод создает новый APILoader (расширяет наверное URLLoader) и возвращает его, чтобы основной контроллер мог подписаться на его COMPLETE и взять именно свою data по факту загрузки.

Что правильно, что ошибка, что чушь по неопытности — хочу как-то разобраться в этом вопросе основательно.

[etc]

Непонятна роль APIController-а. Точнее понятна, но результат парсить должен именно он и выдавать его уже в виде удобоваримых данных MenubarController-у. Либо парсить должна сама модель. И возвращать APILoader не имеет смысла, слушать его должен сам APIController, а по окончании загрузки слать событие COMPLETE. Сейчас в APIController получается единственный метод, содержащий три строчки.

[Zebestov]

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

Непонятна роль APIController-а. Точнее понятна, но результат парсить должен именно он и выдавать его уже в виде удобоваримых данных MenubarController-у. Либо парсить должна сама модель.

Предполагалось, что APIController — это общий для всего приложения класс, задача которого обеспечивать запросы к API серверу текущей среды (vkontakte, facebook и также просто сайт приложения в сети интернет). Он единственный знает (при инициализации), в какой среде сейчас запущено приложение и делает выборку нужных данных соответствующим образом. Поэтому, в силу отличий API разный сетей, для запросов к нему внутри приложения формируется некий универсальный формат. То же для ответов.
Вот теперь больше информации о том, что я хочу сделать. Все очень сырое и совет/отбраковка приветствуются.
Из всего этого я подумал, что APIController парсить ничего не должен. Да и слово парсить наверное громко для процесса из моей схемы... это скорее выборка только нужных данных для MenubarModel, который сейчас должен иметь по каждому пункту меню только его id и title. Вот такой был ход мысли.

Насчет "парсить в модели". По сути модель тоже в праве знать о формате ответов на API запросы, принятом в приложении, чтобы самостоятельно разобрать вошедший Object и сохранить в себе только нужное. Так будет правильней? (а то она вообще тогда какая-то вот-вот нафиг ненужная)

И возвращать APILoader не имеет смысла, слушать его должен сам APIController, а по окончании загрузки слать событие COMPLETE.

Единственная причина такой схемы — обеспечить ожидание именно своих данных в случае, когда к APIController-у обратится подряд несколько контроллеров каждый со своим "заказом". Ведь если слушать COMPLETE самого APIController, то поди разбери чей это ответ пришел? Не ну можно придумать схему разбора по какому-то requestID, который возвращал бы метод request() (сейчас он возвращает ссылку на APILoader). Так будет правильней?

Сейчас в APIController получается единственный метод, содержащий три строчки.

Ну выше я уже описал, что по сути внутри у APIController целый механизм, ограждающий приложение от среды с ее особенностями.

Спасибо за ответы! Надеюсь разобраться с вашей помощью.

[Tr1te]

Не понимаю зачем сонтроллеру передавать ссылку на себя моделе и вьюверу, если они являются детьми и они могут к нему обращаться как

parent.

?