вместо
поэтому и
Никакого "умножения сущностей" нет - есть элементарнейшая лень, которая - двигатель прогресса. :) Да - не по-человечески, не по ООПовски, но код читабельный и понятный.
Появились мысли сделать систему на сигналах, а не на событиях - там наверное получится покрасивее..

Вот кстати созрели новые вопросы:

1) Взглянул на схему etc. Не понял, почему бабблинг идёт по дате, и уходит в контроллер. С чего контроллеру то нужны события даты (это модель так обозвана, или это ерунда из базы данных?)

2) Всё чаще код в контроллерах у меня сокращается, и в модели появляются много методов, таких как addLine() и на них похожих. В итоге, по идее контроллер должен заниматься такой ерундой, как подготовить что нибудь и добавить в модель, а у меня модель сама подготавливает что ей надо (не в ущерб гибкости, конечно) и добавляет в себя. Насколько это плохо?

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

1) Дата только хранит данные. Контроллер потенциально может слушать модель, т. к. он не единственный контроллер, который может её изменять.

2) Если речь идёт только о том, чтобы добавить некие данные на основе входящих аргументов, то это вполне неплохо. Если же модель начинает содержать логику, в результате которой изменяются другие составляющие модели (вроде списывания денег с персонажа при добавлении предмета) — то это не её обязанность.

1) Ну дата тогда получается что это модель? Модель тоже только хранит данные. Ну и оповещает об изменении.

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

Почему то думал, что поступаю не совсем хорошо, но забил на правила хорошего тона когда понял, что мне это удобно, а тут оказалось что это ещё и правильно. Здорово %)

1) Да, дата — это модель;

2) В таком варианте такие методы вполне себе оправданы и должны быть у модели, а не у контроллера.

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

Собственно, меня долгое время смущало вот это:
1) Имеется ввиду модель или реальная база данных? Когда я спрашивал я имел ввиду внешнюю БД, например, сервер.

2) Как будет грамотнее: заставить модель получить информацию с базы (и периодически её обновлять, например сделать в ней сокет, а при поступлении байтов просить контроллер что-то сделать) или заставить это делать контроллер, периодически записывая результаты в модель?

1) Нет, это иерархическая модель;

2) Можно написать отдельный контроллер модели, который работает с соединением и помещает приходящие данные в модель.

2) То есть одна модель на 2 контроллера (один работает с сервером, другой уже берёт данные и обрабатывает их)? Понятно, спасибо.

Нет, два контроллера на одну модель. Один «побольше», логический, второй «поменьше», для работы с сервером через соединение и засовыванием данных в модель. У обоих контроллеров есть ссылка на модель. Между контроллерами может быть вполне себе событийная связь (от младшего к старшему) и как минимум прямая (вызов методов от старшего к младшему).

Я не то же самое сказал? =)

Спасибо большое )

Не совсем, обязанности были другие.

а как всплывают события не у экранных объектов? какая-то собственная реализация с генерацией только что принятоно от "ребенка" события с помощью e.clone()? или я что-то пропустил :umnik2:

я, например, в реализации евентов для as2, диспатчил срузу у парента, если событие всплываемое и у парента есть dispatchEvent..

ну это на один уровень вверх. а если надо более абстрактно? ну в принципе понял — руками.

В целом как то так.

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

сигнал-слот?

Что, мы опять делаем приложения, вычисляющие геном человека за 30 секунд с триллионами итераций?

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

@Котяра: что-то вроде, но более похожий на нативный EventDispatcher. Это мысли, ещё не факт что даже попробую это сделать.

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

Я тебя не понял.
Я делаю событийную модель как у DO - это удобно, но не лучше?
Что подразумевается под лучше?

Это как раз у тебя надо спросить.

Я прекрасно понимаю, что понятие "лучше" чисто субъективное )
Мне интересна твоя точка зрения, почему событийная модель DO для тебя не лучше.

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

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

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

Первое.

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

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

[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 по факту загрузки.

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

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

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

Tr1te, модель ничего не знает о контроллере и вьювере, если что. А обращение к родителю в принципе не есть ООП-подход.

Простите за оффтоп, но прицепите уже эту тему вверх раздела. Полезность ее зашкаливает.

Done.

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

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


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

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

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

Zebestov, тогда APIController должен отдавать в универсальном формате, скажем, в виде экземпляра какого-нибудь универсального APIUserData. Парсить — это к примеру из xml/json в этот самый APIUserData. В модель можно сувать через addAPIUser.

Кроме того, не вижу никакого смысла делать запросы к нему из нескольких мест, этим должен заниматься основной контроллер приложения, а APIController в ответ будет вызывать методы в нём (через client).

Чувствую, что что-то правильное, но ничего вообще не могу разобрать =(
Запросы из нескольких мест — это в плане передавать APIController (один из основных контроллеров приложения) ссылкой в контроллеры для того, чтобы они могли вызывать его request()? Т.е. так делать не годится?

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