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 aha...@adobe.com 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 nigel.mag...@gmail.com Reply-To: flexcoders@yahoogroups.com flexcoders@yahoogroups.com Date: Tuesday, October 1, 2013 4:38 AM To: flexcoders@yahoogroups.com flexcoders@yahoogroups.com 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 aha...@adobe.com 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 nigel.mag...@gmail.com Reply-To: flexcoders@yahoogroups.com flexcoders@yahoogroups.com Date: Friday, September 27, 2013 6:36 AM To: flexcoders@yahoogroups.com flexcoders@yahoogroups.com 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?
Re: [flexcoders] Automation and Application Domains
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 nigel.mag...@gmail.commailto:nigel.mag...@gmail.com Reply-To: flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com Date: Thursday, October 3, 2013 2:16 AM To: flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com 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 aha...@adobe.commailto:aha...@adobe.com 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 nigel.mag...@gmail.commailto:nigel.mag...@gmail.com Reply-To: flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com Date: Tuesday, October 1, 2013 4:38 AM To: flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com 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 aha...@adobe.commailto:aha...@adobe.com 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 nigel.mag...@gmail.commailto:nigel.mag...@gmail.com Reply-To: flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com Date: Friday, September 27, 2013 6:36 AM To: flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com 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
Re: [flexcoders] Automation and Application Domains
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 nigel.mag...@gmail.commailto:nigel.mag...@gmail.com Reply-To: flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com Date: Tuesday, October 1, 2013 4:38 AM To: flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com 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 aha...@adobe.commailto:aha...@adobe.com 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 nigel.mag...@gmail.commailto:nigel.mag...@gmail.com Reply-To: flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com Date: Friday, September 27, 2013 6:36 AM To: flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com 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?
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 aha...@adobe.com 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 nigel.mag...@gmail.com Reply-To: flexcoders@yahoogroups.com flexcoders@yahoogroups.com Date: Friday, September 27, 2013 6:36 AM To: flexcoders@yahoogroups.com flexcoders@yahoogroups.com 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?
[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?
Re: [flexcoders] Automation and Application Domains
Did you actually try it and found that it fails? I would think it should be able to introspect child appdomains. From: Nigel Magnay nigel.mag...@gmail.commailto:nigel.mag...@gmail.com Reply-To: flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com Date: Friday, September 27, 2013 6:36 AM To: flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com 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?