2012-02-28 2 views
0

nous avons deux applications (pas de modules, deux applications indépendantes!): A et B. tous deux sont gérés par Parsley et nous aimerions incorporer B dans A en utilisant SWFLoader (mais, et j'insiste sur le fait que nous ne voulons pas "connecter" ces applications en utilisant Persil, nous voulons juste faire un encastrement Flash normal).persil et swfloader: propagation de domaine célèbre

qui est inclure du code:

<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 il fonctionne quand j'intégrer B dans une application factice sans persil.

cependant, quand je copier-coller que intégrer le code dans l'application en direct A, persil lance cette fameuse erreur:

ReferenceError: Specified ApplicationDomain does not contain the class _B_mx_managers_SystemManager

même si la vue contenant code d'intégration est Persil configuré non (et doesn pas de tag <Configure/>).

Je ne peux malheureusement pas poster ceci sur les forums de Parsley et googler n'a pas aidé car il semble que les gens ne font pas trop souvent d'applications. Donc la question est, pourquoi cette erreur se produit (Parsley ne devrait pas se soucier de choses dans l'application intégrée, devrait-il?) Et comment peut dire à Parsley d'utiliser correctement mon childDomain?

+0

avez-vous progressé? J'ai le même problème, sans solution pour le moment. – robmcm

Répondre

1

Le problème est que le persil bouillonne d'événements de la liste d'affichage de sorte qu'un contexte peut les utiliser pour injecter des propriétés, etc. Malgré le fait que votre application sous

est dans un domaine d'application séparée, les événements peuvent encore bouillonner de l'enfant du chargeur de swf au parent et ainsi de suite. Qu'est-ce qui se passe, c'est que votre sous-application fait bouillonner les événements qui sont traités par votre contexte shells (ou wrapper/loader applications), mais quand persil tente de réfléchir sur cet objet, il ne peut pas parce que l'objet doesn ' t existe dans son domaine d'application.

La solution consiste à empêcher ces événements d'accéder au contexte de persil de votre application shell. Vous pouvez le faire de plusieurs façons, par exemple vous pouvez simplement ajouter des écouteurs pour les événements et arrêter leur propagation. Cependant, cela signifierait que vous auriez à ajouter des écouteurs pour tous les événements de Parsley, ce qui pourrait changer dans le futur. Une meilleure solution consiste à créer un nouveau contexte dans le parent de votre SWFLoader avec un autowireFilter qui renvoie ViewAutowireMode.NEVER pour les objets displayObjects qui lui sont passés. Ce contexte les empêchera de continuer à bouillonner et empêchera le persil de réfléchir sur eux, ce qui empêchera le problème de ne pas être dans le domaine d'application.

Voir: org.spicefactory.parsley.core.view.impl.DefaultViewAutowireFilter org.spicefactory.parsley.core.builder.impl.DefaultCompositeContextBuilder http://opensource.powerflasher.com/jira/browse/PSL-587

Hope this helps.

0

la réponse ci-dessus est correcte.

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