persil et swfloader :propagation de domaine célèbre

Question

nous avons deux applications (pas de modules, deux applications indépendantes !) : A et B.les deux sont gérés par Persley et nous aimerions intégrer B dans A en utilisant SWFLoader (mais, et j'insiste sur le fait que nous ne voulons pas "connecter" ces applications en utilisant Parsley, nous voulons juste faire une intégration Flash normale).

c'est le code intégré :

<fx:Script>
<![CDATA[
    [Bindable]
    private var childDomain:ApplicationDomain =
        new ApplicationDomain(ApplicationDomain.currentDomain);

]]>
</fx:Script>

<mx:SWFLoader width="100%" height="100%" source="B.swf" 
    complete="initNestedAppProps(SWFLoader(event.currentTarget).content);"
    loaderContext="{new LoaderContext(false, childDomain, SecurityDomain.currentDomain)}"/>         

et ça marche quand j'intègre B dans une application factice sans persil.

cependant, lorsque je copie-colle ce code intégré dans une application en direct A, Parsley renvoie cette fameuse erreur :

ReferenceError: Specified ApplicationDomain does not contain the class _B_mx_managers_SystemManager

même si la vue qui contient le code d'intégration n'est pas configurée pour Parsley (et n'a pas <Configure/> étiqueter).

Je ne peux malheureusement pas publier ceci sur les forums Parsley et la recherche sur Google n'a pas aidé car il semble que les gens ne font pas trop souvent l'intégration d'applications.

la question est donc de savoir pourquoi cette erreur se produit (Parsley ne devrait pas se soucier des éléments de l'application intégrée, n'est-ce pas ?) et comment peut-il dire à Parsley d'utiliser correctement mon childDomain?

Answer 1

Le problème est que Parsley fait remonter les événements dans la liste d'affichage afin qu'un contexte puisse les utiliser pour injecter des propriétés, etc.

Malgré le fait que votre sous-application se trouve dans un domaine d'application distinct, les événements peuvent toujours remonter de l'enfant du chargeur swf au parent, etc.

Ce qui se passe, c'est que votre sous-application bouillonne d'événements qui sont gérés par le contexte de vos shells (ou applications wrapper/loader). Cependant, lorsque Parsley essaie ensuite de réfléchir sur cet objet, il ne peut pas car l'objet n'existe pas dans son domaine d'application.

La solution consiste à empêcher ces événements d'accéder au contexte persley de votre application shell.Vous pouvez procéder de plusieurs manières, par exemple en ajoutant simplement des auditeurs pour les événements et en arrêtant leur propagation.Cependant, cela signifierait que vous devrez ajouter des auditeurs pour tous les événements Parsley, ce qui pourrait changer à l'avenir.Une meilleure solution consiste à créer un nouveau contexte dans le parent de votre SWFLoader doté d'un autowireFilter qui renvoie ViewAutowireMode.NEVER pour les displayObjects qui lui sont transmis.

Ce contexte les empêchera de bouillonner davantage et empêchera le persil de réfléchir sur eux, et donc arrêtera le problème de leur absence dans le domaine d'application.

Voir:org.spicefactory.psley.core.view.impl.defaultViewAutowireFilter org.spicefactory.Parsley.core.builder.impl.defaultCompiteContextBuilderhttp://opensource.powerflasher.com/jira/browse/PSL-587

J'espère que cela t'aides.

Answer 2

la réponse ci-dessus est correcte.

dans notre cas, j'ai résolu le problème en écrivant un module flex et en utilisant ModuleLoader au lieu de SWFLoader, qui est bien intégré à Parsley.