Обработчик события не "успевает"

[alexcon314]

наверняка должен быть какой-нибудь красивый "костыль"

Найдете - отпишитесь.

[steelcut]

Но все-таки согласитесь, вы не можете getSomeStringFromXml("blabla"); прежде, чем вы загрузите сам xml? А грузится он может секунду, а может 20 секунд, интернет у всех разный.

Вот и получается что жарить рыбу вы можете начать только получив ее в руки.

Насчет использования того же класса, отделите мух от котлет:
customFunction - это ваш getMedia()

package 
{
	import flash.net.URLRequest;
	import flash.net.*;
	import flash.events.Event;
 
	public class MyLoader
	{
		private var Loader:URLLoader;
		private var customFunction:Function;
 
		public function MyLoader(fileName:String, _customFunction:Function):void
		{
			customFunction = _customFunction;
			xmlLoader = new URLLoader();
			xmlLoader.addEventListener(Event.COMPLETE, customFunction, false, 0, true);
			xmlLoader.load(new URLRequest(fileName));
		}
 
		private function onComplete(e:Event) {
			xmlLoader.removeEventListener(Event.COMPLETE, customFunction);
			customFunction(e);
		}
 
	}
}

То есть где вам надо используйте на здоровье:

//какой-то ваш класс
var L:myLoader = new MyLoader (fileName, getMedia);
...
public function getMedia(e:Event){
myXML = new XML(e.target.data);
}

[Wolsh]

Хм. Пока кадр не загрузится, он не может быть показан; при этом следующий кадр, может быть в сто раз легче предыдущего, показан не будет также. Именно это я и имел в виду, говоря, что Вы мыслите кадрами. Потому что именно так Вы и мыслите - один кубик, ПОТОМ второй, ПОТОМ третий. Но в программе, в отличие от мультика, цепочка другая. Потому что программе нужна ГИБКОСТЬ. Программа состоит из модулей, которые отнюдь не выполняются один за другим, как кадры в мультике. Эти модули включаются как реакция на события, потому что всякая (ну 90%) программа работает с событиями - акциями юзера или событиями, возникающими при получении и обработке данных. Время возникновения этих событий заранее не известно, как и их последовательность (в случае с действиями юзера). Это - асинхронность. Программа не может встать и умереть, пока Вы не нажмете ОДНУ определенную кнопку (аналогия с Вашимм представлением, как должны загружаться данные). Ваше желание запихать всю функциональность класса в конструктор - бессмысленно и противоречит всякой логике класса как объекта, обладающего методами и свойствами.
Еще раз - программа не останавливается и не ждет, пока что-то загрузится, чтобы начать выполнять СЛЕДУЮЩУЮ строчку кода. Это не кадры. Это - гибкость.

[Mur4ik]

из xmlLoadHandler пошлите событие о том что данные загружены, например так

private function xmlLoadHandler(e:Event):void
{
        dispatchEvent(e); // просто пропихиваете событие дальше
        trace(0);
}

в классе, который вызывает loadXml(pathToXML:String) подписываетесь на это событие и в обработчике уже хоть 1000 методов вызывайте по типу getMedia()

[koIIImarik]

участки кода отличаются негибкостью и "костылизмом"

Если честно, то мне не понятно, почему вы называете «костылём» слушателя окончания загрузки файла. Как вам уже выше правильно написали, мы не можем обратиться к загруженному XML до его полной загрузки. Это логично, это правильно и это не костыль.

мне нужен класс который получает xml, обрабатывает, и отдает результат

А что вам мешает создать такой класс? =) И если вам нужен полиформизм, то создайте класс, и функцию, допустим initAfterLoadingXML, которая будет вызываться после окончания загрузки XML, и в котором будут происходить все необходимые действия с загруженным XML. А в дочерних классах необходимо будет просто перезаписать функцию initAfterLoadingXML и реализовать «инициализацию» для конкретного дочернего класса.

[Vier]

Как вариант, можно по событию загрузки xml вешать в классе флаг.
Пока флаг false, вызовы всех методов, связанных с xml (который еще недогружен), пусть кидают эксепшены.