Automation and Application Domains

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Automation and Application Domains

Nigel Magnay
We are using RIAtest, which uses flex automation to test some applications.

Reading the flex documentation, it contains the following:

Testing applications that load external libraries

... A library that is loaded at run time (including run-time shared
libraries (RSLs)) must be loaded into the ApplicationDomain of the loading
application. If the SWF file used in the application is loaded in a
different application domain, automated testing record and playback will
not function properly.


This is particularly inconvenient for us; we load UI controls into
separate ApplicationDomains (all children of
ApplicationDomain.currentDomain) because they can have conflicting
classnames, and this allows each form to be generated in isolation, and
they cannot interfere with each other. The thought of having to refactor
hundreds of classes is not appealing.


This seems to prevent RIAtest's inspector from finding child controls
sourced from that loader.

Is there any way around this restriction, perhaps by implementing some kind
of delegate class, or overriding the automation provider to allow it to
callback to discover the applicationdomains it needs to search?
Reply | Threaded
Open this post in threaded view
|

Re: Automation and Application Domains

Alex Harui
Did you actually try it and found that it fails?  I would think it should be able to introspect child appdomains.

From: Nigel Magnay <[hidden email]<mailto:[hidden email]>>
Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Date: Friday, September 27, 2013 6:36 AM
To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: [flexcoders] Automation and Application Domains



We are using RIAtest, which uses flex automation to test some applications.

Reading the flex documentation, it contains the following:

Testing applications that load external libraries

... A library that is loaded at run time (including run-time shared libraries (RSLs)) must be loaded into the ApplicationDomain of the loading application. If the SWF file used in the application is loaded in a different application domain, automated testing record and playback will not function properly.


This is particularly inconvenient for us; we load UI controls into separate ApplicationDomains (all children of ApplicationDomain.currentDomain) because they can have conflicting classnames, and this allows each form to be generated in isolation, and they cannot interfere with each other. The thought of having to refactor hundreds of classes is not appealing.


This seems to prevent RIAtest's inspector from finding child controls sourced from that loader.

Is there any way around this restriction, perhaps by implementing some kind of delegate class, or overriding the automation provider to allow it to callback to discover the applicationdomains it needs to search?



Reply | Threaded
Open this post in threaded view
|

Re: Automation and Application Domains

Nigel Magnay
Yes, it seems to fail.

RIAtest has a component 'inspector', which shows the component tree. If my
UI component is in a different (child) application domain, it never appears
in the inspector (and events from manipulating it never get received).

When I raised a ticket against it (and asked if there were some API that I
could use to perhaps inform it more directly to my new application
domains), they pointed me to the supposed flex automation restriction -
hence me starting to dig to see if I might be able to overcome the
restriction - perhaps by generating shim classes or delegates..



On Fri, Sep 27, 2013 at 7:25 PM, Alex Harui <[hidden email]> wrote:

> **
>
>
> Did you actually try it and found that it fails?  I would think it should
> be able to introspect child appdomains.
>
> From: Nigel Magnay <[hidden email]>
> Reply-To: "[hidden email]" <[hidden email]>
> Date: Friday, September 27, 2013 6:36 AM
> To: "[hidden email]" <[hidden email]>
> Subject: [flexcoders] Automation and Application Domains
>
>
>
> We are using RIAtest, which uses flex automation to test some applications.
>
> Reading the flex documentation, it contains the following:
>
> Testing applications that load external libraries
>
> ... A library that is loaded at run time (including run-time shared
> libraries (RSLs)) must be loaded into the ApplicationDomain of the loading
> application. If the SWF file used in the application is loaded in a
> different application domain, automated testing record and playback will
> not function properly.
>
>
> This is particularly inconvenient for us; we load UI controls into
> separate ApplicationDomains (all children of
> ApplicationDomain.currentDomain) because they can have conflicting
> classnames, and this allows each form to be generated in isolation, and
> they cannot interfere with each other. The thought of having to refactor
> hundreds of classes is not appealing.
>
>
> This seems to prevent RIAtest's inspector from finding child controls
> sourced from that loader.
>
> Is there any way around this restriction, perhaps by implementing some
> kind of delegate class, or overriding the automation provider to allow it
> to callback to discover the applicationdomains it needs to search?
>
>  
>
Reply | Threaded
Open this post in threaded view
|

Re: Automation and Application Domains

Alex Harui
Even generating shim classes would result in conflicts if you have more than one definition of a class you are trying to "shim" into the main applicationdomain.

But if you can guarantee there isn't conflicts for a particular test scenario, then maybe you can test by loading into the main app domain.

From: Nigel Magnay <[hidden email]<mailto:[hidden email]>>
Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Date: Tuesday, October 1, 2013 4:38 AM
To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: Re: [flexcoders] Automation and Application Domains



Yes, it seems to fail.

RIAtest has a component 'inspector', which shows the component tree. If my UI component is in a different (child) application domain, it never appears in the inspector (and events from manipulating it never get received).

When I raised a ticket against it (and asked if there were some API that I could use to perhaps inform it more directly to my new application domains), they pointed me to the supposed flex automation restriction - hence me starting to dig to see if I might be able to overcome the restriction - perhaps by generating shim classes or delegates..



On Fri, Sep 27, 2013 at 7:25 PM, Alex Harui <[hidden email]<mailto:[hidden email]>> wrote:


Did you actually try it and found that it fails?  I would think it should be able to introspect child appdomains.

From: Nigel Magnay <[hidden email]<mailto:[hidden email]>>
Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Date: Friday, September 27, 2013 6:36 AM
To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: [flexcoders] Automation and Application Domains



We are using RIAtest, which uses flex automation to test some applications.

Reading the flex documentation, it contains the following:

Testing applications that load external libraries

... A library that is loaded at run time (including run-time shared libraries (RSLs)) must be loaded into the ApplicationDomain of the loading application. If the SWF file used in the application is loaded in a different application domain, automated testing record and playback will not function properly.


This is particularly inconvenient for us; we load UI controls into separate ApplicationDomains (all children of ApplicationDomain.currentDomain) because they can have conflicting classnames, and this allows each form to be generated in isolation, and they cannot interfere with each other. The thought of having to refactor hundreds of classes is not appealing.


This seems to prevent RIAtest's inspector from finding child controls sourced from that loader.

Is there any way around this restriction, perhaps by implementing some kind of delegate class, or overriding the automation provider to allow it to callback to discover the applicationdomains it needs to search?




Reply | Threaded
Open this post in threaded view
|

Re: Automation and Application Domains

Nigel Magnay
Yes, it does seem a problem - hence me trying to figure out if it was a
'burned in' limitation of the flash runtime, or something I could find a
workaround for.



On Wed, Oct 2, 2013 at 6:58 PM, Alex Harui <[hidden email]> wrote:

> **
>
>
> Even generating shim classes would result in conflicts if you have more
> than one definition of a class you are trying to "shim" into the main
> applicationdomain.
>
> But if you can guarantee there isn't conflicts for a particular test
> scenario, then maybe you can test by loading into the main app domain.
>
> From: Nigel Magnay <[hidden email]>
> Reply-To: "[hidden email]" <[hidden email]>
> Date: Tuesday, October 1, 2013 4:38 AM
> To: "[hidden email]" <[hidden email]>
> Subject: Re: [flexcoders] Automation and Application Domains
>
>
>
> Yes, it seems to fail.
>
> RIAtest has a component 'inspector', which shows the component tree. If my
> UI component is in a different (child) application domain, it never appears
> in the inspector (and events from manipulating it never get received).
>
> When I raised a ticket against it (and asked if there were some API that I
> could use to perhaps inform it more directly to my new application
> domains), they pointed me to the supposed flex automation restriction -
> hence me starting to dig to see if I might be able to overcome the
> restriction - perhaps by generating shim classes or delegates..
>
>
>
> On Fri, Sep 27, 2013 at 7:25 PM, Alex Harui <[hidden email]> wrote:
>
>> **
>>
>>
>> Did you actually try it and found that it fails?  I would think it should
>> be able to introspect child appdomains.
>>
>> From: Nigel Magnay <[hidden email]>
>> Reply-To: "[hidden email]" <[hidden email]>
>> Date: Friday, September 27, 2013 6:36 AM
>> To: "[hidden email]" <[hidden email]>
>> Subject: [flexcoders] Automation and Application Domains
>>
>>
>>
>> We are using RIAtest, which uses flex automation to test some
>> applications.
>>
>> Reading the flex documentation, it contains the following:
>>
>> Testing applications that load external libraries
>>
>> ... A library that is loaded at run time (including run-time shared
>> libraries (RSLs)) must be loaded into the ApplicationDomain of the loading
>> application. If the SWF file used in the application is loaded in a
>> different application domain, automated testing record and playback will
>> not function properly.
>>
>>
>> This is particularly inconvenient for us; we load UI controls into
>> separate ApplicationDomains (all children of
>> ApplicationDomain.currentDomain) because they can have conflicting
>> classnames, and this allows each form to be generated in isolation, and
>> they cannot interfere with each other. The thought of having to refactor
>> hundreds of classes is not appealing.
>>
>>
>> This seems to prevent RIAtest's inspector from finding child controls
>> sourced from that loader.
>>
>> Is there any way around this restriction, perhaps by implementing some
>> kind of delegate class, or overriding the automation provider to allow it
>> to callback to discover the applicationdomains it needs to search?
>>
>>
>  
>
Reply | Threaded
Open this post in threaded view
|

Re: Automation and Application Domains

Alex Harui
A class's identifier is only as unique as its fully qualified name.  You can think of an ApplicationDomain as an Object with slots for each class as in:

var appdom:Object = {
"flash.display.DisplayObject" : flash.display.DisplayObject;
"mx.core.UIComponent": mx.core.UIComponent;
}

with the exception that, once a slot is set, you can't overwrite it: first-in-wins.  If two separate SWFs supply different definitions the second one will lose out and that can cause issues with code that depends on the lost definition.  That is baked into the runtime.

What is also baked into the runtime is a lack of an API to take an object and find its ApplicationDomain.  This makes it impossible to write a universal, works-everywhere, "get the class definition for this object".

That said, Flex has some infrastructure to allow a main Flex SWF to find the ApplicationDomain of a child Flex SWF (but not any non-Flex child SWF) and therefore take an object and find its ApplicationDomain and thus its class definition.   Automated Testing code could have leveraged this infrastructure, but apparently didn't.  Not sure why, probably because there is no official documentation on how to do that, and maybe because it would fail for non-Flex SWFs.

HTH,
-Alex
From: Nigel Magnay <[hidden email]<mailto:[hidden email]>>
Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Date: Thursday, October 3, 2013 2:16 AM
To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: Re: [flexcoders] Automation and Application Domains



Yes, it does seem a problem - hence me trying to figure out if it was a 'burned in' limitation of the flash runtime, or something I could find a workaround for.



On Wed, Oct 2, 2013 at 6:58 PM, Alex Harui <[hidden email]<mailto:[hidden email]>> wrote:


Even generating shim classes would result in conflicts if you have more than one definition of a class you are trying to "shim" into the main applicationdomain.

But if you can guarantee there isn't conflicts for a particular test scenario, then maybe you can test by loading into the main app domain.

From: Nigel Magnay <[hidden email]<mailto:[hidden email]>>
Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Date: Tuesday, October 1, 2013 4:38 AM
To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: Re: [flexcoders] Automation and Application Domains



Yes, it seems to fail.

RIAtest has a component 'inspector', which shows the component tree. If my UI component is in a different (child) application domain, it never appears in the inspector (and events from manipulating it never get received).

When I raised a ticket against it (and asked if there were some API that I could use to perhaps inform it more directly to my new application domains), they pointed me to the supposed flex automation restriction - hence me starting to dig to see if I might be able to overcome the restriction - perhaps by generating shim classes or delegates..



On Fri, Sep 27, 2013 at 7:25 PM, Alex Harui <[hidden email]<mailto:[hidden email]>> wrote:


Did you actually try it and found that it fails?  I would think it should be able to introspect child appdomains.

From: Nigel Magnay <[hidden email]<mailto:[hidden email]>>
Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Date: Friday, September 27, 2013 6:36 AM
To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: [flexcoders] Automation and Application Domains



We are using RIAtest, which uses flex automation to test some applications.

Reading the flex documentation, it contains the following:

Testing applications that load external libraries

... A library that is loaded at run time (including run-time shared libraries (RSLs)) must be loaded into the ApplicationDomain of the loading application. If the SWF file used in the application is loaded in a different application domain, automated testing record and playback will not function properly.


This is particularly inconvenient for us; we load UI controls into separate ApplicationDomains (all children of ApplicationDomain.currentDomain) because they can have conflicting classnames, and this allows each form to be generated in isolation, and they cannot interfere with each other. The thought of having to refactor hundreds of classes is not appealing.


This seems to prevent RIAtest's inspector from finding child controls sourced from that loader.

Is there any way around this restriction, perhaps by implementing some kind of delegate class, or overriding the automation provider to allow it to callback to discover the applicationdomains it needs to search?





Reply | Threaded
Open this post in threaded view
|

Drag and rotate around center on mouse movement in Flex

anas naeem
Hi All,

Hope every one is doing great . I am facing a small issue while try to achieve drag and rotate around center on mouse movement.

I have achieved how to drag rotate around center of an object (ui component) on mouse movement but it rotates around top left corner which is the default behaviour. I used matrix transformation concept also by looking at many solutions out there on google but my problem is that i want to rotate the component aroun center with a speed that is synchronized with mouse movement and also the component would be rotating around center either clockwise or anti-clockwise movement of the mouse pointer...

Using matrix transformation the issue is that it rotates on a constant speed and also I have no way to rotate it either clockwise or anti-clockwise based upon mouse movement , The only i could achieve it using the matrix concept is by placing a check for event.ctrlKey and then only i could rotate it around center either clockwise or anti-clockwise

I know I am doing something silly in what I am trying to achieve but please any help or suggestion in right direction  would be greatly appreciated oh and sorry for my bad english.

Thanks all in advance.

Regards
Anas.