flash.utils.getDefinitionByName против методов определения класса ApplicationDomain

Question

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

1. ApplicationDomain. getDefinition / hasDefinition / getQualifiedDefinitionNames (только Flash Player 11.3+, без документов)
2. getDefinitionByName

Понятно, что существует иерархия доменов приложений и что определения могут быть видны в одних доменах приложений, а не в других. Например, будет ли ApplicationDomain.getDefinition возвращать определение, которое не определено в данном домене приложения, но доступно из него? (например, если домен является дочерним доменом, и мы ищем определение, определенное в родительском объекте?) Документация для ApplicationDomain просто говорит: "Загруженные классы определяются только тогда, когда их родительский объект еще не определил их". но в нем также говорится: "(ApplicationDomains) позволяют существовать множественным определениям одного и того же класса и позволяют дочерним элементам повторно использовать родительские определения".

В документации также указывается, что getDefinitionByName возвращает определения классов, тогда как ApplicationDomain.getDefinition возвращает определения пространств имен и функций в дополнение к определениям классов.

Предполагая, что меня интересуют только определения классов, какие ApplicationDomains выполняет поиск getDefinitionByName? (например, все домены, только текущий домен / домен вызывающего абонента или любые домены, доступные для вызывающего абонента?)

Этот первоначальный тест сбивает с толку:

import flash.system.ApplicationDomain;
var d:ApplicationDomain = new ApplicationDomain( ApplicationDomain.currentDomain ); //child of current domain
trace(ApplicationDomain.currentDomain.hasDefinition("flash.display.DisplayObject")); //true
trace(ApplicationDomain.currentDomain.getQualifiedDefinitionNames().length); //1 (the main timeline class definition only: Untitled_fla::MainTimeline) 
trace(d.hasDefinition("flash.display.DisplayObject")); //false

В приведенном выше тесте, с одной стороны, getQualifiedDefinitionNames сообщает, что в текущем домене приложения определен только основной класс временной шкалы, но getDefinition возвращает true для DisplayObject, указывая, что он сообщает о существовании определений в родительском (системном) домене, но окончательный след в домене внука противоречит этому, возвращая false.

ApplicationDomain.currentDomain.parentDomain также возвращает значение null, что прямо противоречит следующим инструкциям документации: "Системный домен содержит все домены приложений, включая текущий домен..." и "Каждый домен приложения, кроме системного домена, имеет связанный родительский домен.. Родительским доменом домена приложения вашего основного приложения является системный домен. "

Противоречие очень очевидно здесь, где currentDomain имеет определение, но когда вы создаете дочерний домен и обращаетесь к родительскому домену, который должен быть currentDomain, он внезапно сообщает, что не содержит определения:

trace(ApplicationDomain.currentDomain.hasDefinition("flash.display.DisplayObject")); //true
trace((new ApplicationDomain( ApplicationDomain.currentDomain )).parentDomain.hasDefinition("flash.display.DisplayObject")); //false! why?

Answer 1

Эта страница является довольно полной: http://www.senocular.com/flash/tutorials/contentdomains/?page=2 Мне удалось решить пару загадок, но основной вопрос изложен выше (особенно в отношении объема getDefinitionByName) все еще стоит. Я просто хотел опубликовать ответ для того, что я смог решить.

Получение parentDomain возвращает значение NULL, если родительский домен является системным доменом. Таким образом, хотя parentDomain является системным доменом, свойство parentDomain в любом случае возвращает значение null. Так оно и есть. К сожалению, это делает системный домен недоступным, например, для перечисления классов через getQualifiedDefinitionNames.

Что касается моего начального теста, кажется, что создание нового ApplicationDomain создает мертвый объект до тех пор, пока SWF-файл не будет загружен в этот домен. Например, создание дочернего домена текущего домена и вызов на нем hasDefinition вернет false, но если вы назначите тот же самый экземпляр контексту загрузчика и передадите его в Loader.load, после завершения загрузки вы можете вызвать hasDefinition для экземпляр, который первоначально возвратил ложь, и он возвратит истину вместо этого. Таким образом, вы можете создать ApplicationDomain с родителем, но он не будет работать, пока он не будет активно использоваться.

var d:ApplicationDomain = new ApplicationDomain( ApplicationDomain.currentDomain ); //child of current domain
trace(d.hasDefinition( "flash.display.DisplayObject" )); //false for now...
var l:Loader = new Loader();
l.load(new URLRequest( "any.swf"), new LoaderContext( false, d ) );
l.contentLoaderInfo.addEventListener( Event.COMPLETE, completed, false, 0, true );
function completed(e:Event ):void
{
    trace(d.hasDefinition( "flash.display.DisplayObject" ); //...and now it's true.
}

Таким образом, может показаться, что ApplicationDomain.getDefinition делает отчеты о классах в родительском, родительском и т. Д. Доменах, но будет делать это только после активации нового экземпляра ApplicationDomain путем загрузки чего-либо в него.

Кроме того, экземпляры ApplicationDomain могут ссылаться на один и тот же домен приложения, но их нельзя сравнивать напрямую. Например, (ApplicationDomain.currentDomain == ApplicationDomain.currentDomain) ложно