Мысли о ResourceManager. Как сделать его удобным?

[etc]

super.getResource(url, className);

[wvxvw]

По поводу XML и т.п. - очень зависит от ваших жизненных привычек. Я вот вошел во вкус, мне нравится, когда билд сложный и куча всего создается во время билда - и мне так удобно (ради интереса подключил ImageMagic к билду + GoogleDocuments [Spreadsheets]). Зато в AS коде я не решаю задачь типа что откуда загружается. А для кого-то это будет пыткой, и наоборот, будет легче загрузить в AS3 (мне скоро мой проект надо будет передать соседу, ну или похоже выглядит, и я не знаю, как он бедняга будет это в Windows собирать - ну, блин, кто ж знал )
Т.е. мне, возможно даже было бы проще во время билда создавать файлы ресурсов и хардкод ссылок на них и всякий обслуживающий код т.как его можно легко сгенерить по шаблону + не нужно уже в готовом приложении решать что откуда берется - если собралось правильно, то и работать будет обязательно, а если не собралось, то сломается прямо у меня, а не у пользователя на островах Франса Иосифа...
Но в таком случае билд - это часть программы, и фактически тот же код пишется, с той только разницей, что он у меня остается, а не уходит пользователю.

[Psycho Tiger]

@expl, а, ты про это. Конечно, это будет. Я старался максимально упростить пример, обсуждаем скорее подход, чем частности )

@gloomyBrain, ну у меня одним менеджером могут пользоваться одновременно 5 разных объектов. Какой объект узнает, от кого пришло сообщение? Путём введения в сообщения идентификатора, который будет выдаваться ещё и по preloadResource... Зачем эта лишняя возня?

@wxvxw, то есть во время билда всё сразу вкомпиливается в swf/генерируется шаблон, в котором прописаны все ресурсы?

@etc, ну url я понимаю. А className то куда? И что метод возвращает?

[maxkar]

Нормальный подход. У меня такой используется, удобно. Называется менеджер правда по-другому, но интерфейс ровно тот же. getResource(string) и preloadResources(...) с колбэком. Вся грязная магия по правильному подсчету загруженных ресурсов для вызова колбэка живет именно в нем. Оно же предотвращает повторную загрузку уже загруженных (и загружаемых) ресурсов. А вот загрузка ресурсов живет уже не в нем. Загрузка живет в загрузчиках, которые передаются менеджеру в конструкторе. Очередями и т.п. заведуют загрузчики (битмапы, swf-ки с классами и т.п.). Конфиги ресурсов идут тоже в загрузчики, в менеджер ничего не идет. Поверх него есть еще простенькая обертка, которая вместо getResource имеет метод createResource и таки служит для создания экземпляров классов (т.е. сразу возвращает DisplayObject).

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

Что касается ошибок. У меня обработчик ошибок может быть всунут в "практически любое место". Это (в порядке убывания приоритета) обработчик, переданный в preloadResources, обработчик из конструктора менеджера, обработчик в лоадере. Работает только наиболее приоритетный (если он есть ).

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

[expl]

2maxkar: т.е. основной принцип "предзагрузи" централизованно, а потом дергай createResource в разных частях приложения синхронно(т.е. прямой вызов метода без колбеков)?

События на этом классе неудобны

ИМХО здесь нет разницы - можно сделать и систему с подпиской на несколько колбеков - можно использовать стандартный механизм рассылки события - здесь всё равно не используются ни какие баблинги. И спор события / колбеки - чисто вкусовщина, не имеющая смысла, кроме эстетического.

[etc]

Psycho Tiger, возвращает созданный экземпляр того, чего надо.

[maxkar]

2expl:

2maxkar: т.е. основной принцип "предзагрузи" централизованно, а потом дергай createResource в разных частях приложения синхронно(т.е. прямой вызов метода без колбеков)?

Не, все гораздо хитрее. У меня всякие кнопочки для менюшек, стандартные иконки и тому подобную "статику" ResourceManager не грузит. Для таких ресурсов я использую классы в чистом виде и прямо в коде. При этом приложение таки порезано на отдельные "модули" - загружаемые SWF-ки в том числе с кодом. И один общий загрузчик отслеживает все необходимые зависимости (между библиотеками, ресурсами и т.п.) и правильно подгружает все при обращении.

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

function onServerResponce(data : XML) : void {
  const elements : Array = parseData(data);
  this.loadedData = elements;
  const resources : Array = getRequiredResourcesFor(elements);
  resManager.preloadResources(resources, resouresReady);
}
 
private function resourcesReady() : void {
  showUI();
}

Вот в showUI уже используются готовые данные. Есть еще один момент. После прелоада по части приложения обычно расползается не сам resourceManager а его метод resourceManager.getResource. Т.е. большинство мест имеют метод "получить ресурс" (передаваемый им в качестве параметра) и контракт на то, что все необходимые данные для отображения всегда будут готовы.

По поводу событий. Да, вкусовщина. Но там как раз вопрос в удобстве использования (работать то будет все). В случае событий можно написать стандартный обраобтчик, который вызывает мой callback только тогда, когда все события по другим элементам получены. Затем написать функцию, которая вызывает менеджер и устанавливает этот стандартный обработчик. Только вот я не нашел ни одного сценария, когда мне нужны будут отдельные события. Т.е. все 100% сценариев работают примерно так, как выше в примере. Так что мне цена усложнения API (в моем случае) показалась неоправданной.

2Psycho Tiger: Кстати, советую рассмотреть вариант с передачей имен ресурсов в массиве. При передаче вручную лишняя пара скобок не затруднит. А вот при работе с динамически получаемыми данными вызов vararg-функции будет выглядеть не очень красиво (нужно будет с массивом лишние операции проводить).

[Psycho Tiger]

А вот при работе с динамически получаемыми данными вызов vararg-функции будет выглядеть не очень красиво (нужно будет с массивом лишние операции проводить).

Мне не лениво дописать .apply =)
Расскажите поподробней про парсинг ошибок?

@etc, ResourceManager смотрит на расширение файла и возвращает экземпляр класса по getDefinition, если это .swf или что-нибудь другое, если расширение не swf? Или он работает с чем-то одним?
Ещё интересует прелоадинг ресурсов, я так понял getResource синхронный. И судя по всему он определен во вьюхе, не практикуешь загрузку классов только с кодом?

[maxkar]

Там не только .apply. Там еще shift или unshift для передачи обработчиков. Мне пара квадратных скобок больше нравится.

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

Практически во всех случаях в случае использования менеджера ресурсов ошибки либо ожидаются (и корректно обрабатываются), либо не ожидаются и являются фатальными. По-хорошему, это два разных менеджера с разным API.

public final class GuaranteedResourceManager {
  /** transport type is function(string, function(Object)) : void*/
  public GuaranteedResourceManager(transport : Function) {}
  public function getResource(resource : String) : Object {}
  /** when ready is function() : void */
  public function preloadResources(resources : Array, whenReady : Function) : void {}
}
 
public final class NonguaranteedResourceManager {
  /** transport type is function(string, function(Object), function(String)) */
  public final NonguaranteedResourceManager(transport : Function) {}
  public function getResource(resource : String) : Object {}
  /** whenReady is function() : void 
        onError is function(String, String) : void */
  public function preloadResources(resources : Array, whenReady : Function, onError : Function = null) : void {}
}

Первый работает с "гарантированным" транспортом, который обязательно находит ресурсы. Обработка ошибок - в транспорте. Так как не предполагается, что ошибки могут быть разумно обработаны, во всех случаях обработка будет "фатальной ошибкой". Таскать (или писать) по всему коду обработчики фатальных ситуаций не интересно, поэтому они и в транспорте.

Второй работает с "негарантированным" транспортом. В этом случае клиенты "умеют" обрабатывать непредвиденные ситуации. prealodResources в этом случае пытается загрузить ресурсы. О каждой ошибке уведомляет обработчик ошибок (если он есть). Все ошибки запоминаются. Т.е. повторная попытка preloading'а ресурса просто повторит вызов обработчика (чтобы не издеваться над транспортом, который уже ничего не смог). После того, как по всем ресурсам определился статус (загружен или ошибка), вызывается onComplete.

Для тех экзотических случаев, когда для одних и тех же ресурсов нужна как надежная, так и ненадежная загрузка (я нашел у себя в проекте целое одно такое место ), пишется

public function guaranteedTransportOn(rm : NonguaranteedResourceManager, onError : Function) : Function

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

У меня сейчас используется один обобщенный менеджер, его не очень удобно использовать. Он запоминает отказы, в обработчиках вызывает обработчик ошибки ровно один раз на первой ошибке (и не вызвает whenReady в этом случае). При этом требует в конструктор обработчик ошибок по умолчанию, который используется, в случае, если при вызове не был передан соответствующий обработчик. В 90% случаев при вызове preload обработчик ошибок ему не передается и в 100% случаев в конструктор идет обработчик, который дает фатальную ошибку приложения. Так что оно в конце концов будет заменено на более приличный вариант (что-то вроде описаного выше).

[Psycho Tiger]

Спасибо за разьяснения.
Скомпилировав свои мысли и Ваши я придумал такой вариант: preloadResources будет вызывать callback без параметра, если всё хорошо и callback с ним, (передавая ему, например, ErrorObject), если всё плохо. А тот, кто просил ресурсы сам решит, важно ли ему это: он сможет обойтись маленького пятнышка на солнце, но не сможет без конфиг-хмл-файла.

P.S. а ещё мой менеджер превращается в какую-то странную обёртку над BulkLoader...