Я ничего не имею против этого куска кода в контексте мелкой поделки. Вполне рабочий кусок.
Но зачем тогда выкладывать?
Чтоб тот же апокалипсис подумал что это норм подход и так и дальше надо?

Akopalipsis'a таким куском не вдохновить, он слишком для меня простой :)
я когда думаю о связи с сервером, то почему-то в сторону команд смотрю, не знаю на сколько это правильно. Но был бы рад, если бы мне сказали названия готовых решений, которые можно взять для изучения за идеал. Flox-клиент, это то, что нужно для связи приложения с сервером?

Я думаю это отдельная тема. Хочешь - начни. А тут оффтопить нефиг.

Dukobpa3 - так покажи как надо! Мне вот лично в голову не пришло как здесь сделать событийную модель, может быть не дорос еще, кроме как колбечный порт я ничего не вижу лучше в данной ситуации, а безусловно хочется

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

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

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

но сюда вот из этой схемы http://www.flasher.ru/forum/attachme...0&d=1336316055 у контроллера должна быть прямая ссылка на загрузчик, и они должны обмениваться коммандами, а не контроллер должен слушать загрузчик...

А если нужна очередь, то может id сделать и проверять на currentComplete.
Да и подписку можно по id сделать. Но так как я ещё такого не делал, то согласен, что весу в моих словах - не о чём :)

Ага, очередной костылидзе, тогда и коллбеками обойдемся

Isfet, я бы новый реквест посылал в хэндлере сервисного контроллера где бы и ловил расширенный эвент с urlLoader.data...

Добавлено через 7 минут
Akopalipsis, Вы совешенно правильно рассуждаете. И тут возможно даже не только id, а целый путь к id нужного вида. Все зависит от того уникальный у вас id для вида или вы его индексируете. Допустим, некоторые юниты у Вас повторяются в разных локациях.

вы всегда так сжато и ёмко даете ответы, что я порой не могу ничего понять.

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

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

Добавлено через 5 минут
По началу я тоже считал Babylon странным и читая посты, где над ним немного подсмеивались из-за "ядра", тоже улыбался. Но как только я шагнул в сторону фраймворков, то сразу мне стали не понятны слова непонимания, так как там как раз везде и есть это ядро.