[flexcoders] Re: Duplicate Module Loads - applicationDomain / Shared Code Issues

2009-05-18 Thread Amy 
--- In flexcoders@yahoogroups.com, Alex Harui  wrote:
>
> By “load module 2” did you actually load a second module or is it a 
> second instance of an already loaded module and thus the WebService instance 
> is the same.  Hopefully it is the latter as I wouldn’t have an explanation 
> for the former.
> 
> For the latter, I believe (and I am not the expert on web-services) that 
> every send() method returns an AsyncToken and you can save that away and 
> decide whether to respond to the result event based on the AsyncToken 
> referenced in the result event.

Alex;

You are correct, but possibly a better way to approach this is to attach a 
responder to that token that contains the fault/result handlers local to the 
specific module that called the service, rather than adding an event listener 
directly that will respond to events on all calls and then deciding later 
whether or not to act.

This example 
http://flexdiary.blogspot.com/2009/01/lazy-loading-tree-example-file-posted.html
 doesn't use Modules, but it does show how to use a responder to "route" the 
result of a call back to the specific instance of a class that made the call.

HTH;

Amy

[flexcoders] Re: Duplicate Module Loads - applicationDomain / Shared Code Issues

2009-05-17 Thread Brendan Meutzner 
Alex,

I set it up using your advice for factory.create(), so it's the latter... a new 
instance of the same module.

Yeah, I figured there must be a way to distinguish the eventlistener's 
dispatcher... I'll post my results once I figure it out.

Thanks again for the help.


Brendan



--- In flexcoders@yahoogroups.com, Alex Harui  wrote:
>
> By “load module 2” did you actually load a second module or is it a 
> second instance of an already loaded module and thus the WebService instance 
> is the same.  Hopefully it is the latter as I wouldn’t have an explanation 
> for the former.
> 
> For the latter, I believe (and I am not the expert on web-services) that 
> every send() method returns an AsyncToken and you can save that away and 
> decide whether to respond to the result event based on the AsyncToken 
> referenced in the result event.
> 
> Alex Harui
> Flex SDK Developer
> Adobe Systems Inc.<http://www.adobe.com/>
> Blog: http://blogs.adobe.com/aharui
> 
> From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On 
> Behalf Of Brendan Meutzner
> Sent: Sunday, May 17, 2009 8:26 PM
> To: flexcoders@yahoogroups.com
> Subject: [flexcoders] Re: Duplicate Module Loads - applicationDomain / Shared 
> Code Issues
> 
> 
> 
> 
> 
> Alex,
> 
> That definitely did the trick.
> 
> However...
> 
> I'm using DataService calls inside the modules, and now when event listeners 
> get set for result/fault/conflict events on them, they carry over to the 
> other modules. So if I open module 1, load it up and make a data call, then 
> load module 2, the result event on module 1 & 2 get fired. I can't exactly 
> remove the event listeners on these (which would be the simplest answer) 
> because of the fact that data synchronization is happening through LiveCycle 
> DS.
> 
> I have yet to look into trying to identify the calling module which causes 
> the result event to see if I can single them out and ignore other multiple 
> instances (which I will do tomorrow), but thought I'd post to see if there 
> was an easier solution.
> 
> Thanks very much for your original answer on this... it really helped out :-)
> 
> Brendan
> 
> --- In flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com>, Alex 
> Harui  wrote:
> >
> > In theory, you simply put all shared VO’s in the main app and 
> > don’t mess with applicationDomains.
> >
> > Also in theory, if it is the same module class there is no need to load it 
> > twice, you should instantiate it twice (via factory.create()) and pass it 
> > parameters it needs to make different backend calls. Should take less 
> > memory this way, and might avoid this shared code issue.
> >
> > Modules don’t work if you use â€Å"new ApplicationDomain()” 
> > as there must be shared interfaces between the loader and loadee, and using 
> > applicationDomain.currentDomain will lock the module into memory.
> >
> > Alex Harui
> > Flex SDK Developer
> > Adobe Systems Inc.<http://www.adobe.com/>
> > Blog: http://blogs.adobe.com/aharui
> >
> > From: flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com> 
> > [mailto:flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com>] On 
> > Behalf Of Brendan Meutzner
> > Sent: Saturday, May 16, 2009 3:48 PM
> > To: flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com>
> > Subject: [flexcoders] Duplicate Module Loads - applicationDomain / Shared 
> > Code Issues
> >
> >
> >
> >
> >
> > Hi All,
> >
> > I'm having trouble wrapping my head around an issue I'm facing while 
> > loading the same module twice into my main application.
> >
> > I've got a module which takes a few arguments to load up property data. If 
> > I ask for a different set of data, the same Module class gets loaded, it 
> > just makes different back end calls to populate its data. My module is 
> > located in a different project from my main application, so optimizing to 
> > application isn't an option. However, I am generating a link-report from 
> > the main application, and then using load-externs on the module's compile.
> >
> > 1) I load up an instance of the module, and it retrieves data just fine.
> > 2) I load up a second instance of the same module, but when the data is 
> > returned, I get errors relating to the fact it's trying to set my data 
> > response to a local VO Class which has already been instantiated from the 
> > first module call.
> >
> >
&

RE: [flexcoders] Re: Duplicate Module Loads - applicationDomain / Shared Code Issues

2009-05-17 Thread Alex Harui 
By “load module 2” did you actually load a second module or is it a second 
instance of an already loaded module and thus the WebService instance is the 
same.  Hopefully it is the latter as I wouldn’t have an explanation for the 
former.

For the latter, I believe (and I am not the expert on web-services) that every 
send() method returns an AsyncToken and you can save that away and decide 
whether to respond to the result event based on the AsyncToken referenced in 
the result event.

Alex Harui
Flex SDK Developer
Adobe Systems Inc.<http://www.adobe.com/>
Blog: http://blogs.adobe.com/aharui

From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf 
Of Brendan Meutzner
Sent: Sunday, May 17, 2009 8:26 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Duplicate Module Loads - applicationDomain / Shared 
Code Issues





Alex,

That definitely did the trick.

However...

I'm using DataService calls inside the modules, and now when event listeners 
get set for result/fault/conflict events on them, they carry over to the other 
modules. So if I open module 1, load it up and make a data call, then load 
module 2, the result event on module 1 & 2 get fired. I can't exactly remove 
the event listeners on these (which would be the simplest answer) because of 
the fact that data synchronization is happening through LiveCycle DS.

I have yet to look into trying to identify the calling module which causes the 
result event to see if I can single them out and ignore other multiple 
instances (which I will do tomorrow), but thought I'd post to see if there was 
an easier solution.

Thanks very much for your original answer on this... it really helped out :-)

Brendan

--- In flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com>, Alex 
Harui  wrote:
>
> In theory, you simply put all shared VO’s in the main app and don’t mess 
> with applicationDomains.
>
> Also in theory, if it is the same module class there is no need to load it 
> twice, you should instantiate it twice (via factory.create()) and pass it 
> parameters it needs to make different backend calls. Should take less memory 
> this way, and might avoid this shared code issue.
>
> Modules don’t work if you use “new ApplicationDomain()” as there must 
> be shared interfaces between the loader and loadee, and using 
> applicationDomain.currentDomain will lock the module into memory.
>
> Alex Harui
> Flex SDK Developer
> Adobe Systems Inc.<http://www.adobe.com/>
> Blog: http://blogs.adobe.com/aharui
>
> From: flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com> 
> [mailto:flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com>] On 
> Behalf Of Brendan Meutzner
> Sent: Saturday, May 16, 2009 3:48 PM
> To: flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com>
> Subject: [flexcoders] Duplicate Module Loads - applicationDomain / Shared 
> Code Issues
>
>
>
>
>
> Hi All,
>
> I'm having trouble wrapping my head around an issue I'm facing while loading 
> the same module twice into my main application.
>
> I've got a module which takes a few arguments to load up property data. If I 
> ask for a different set of data, the same Module class gets loaded, it just 
> makes different back end calls to populate its data. My module is located in 
> a different project from my main application, so optimizing to application 
> isn't an option. However, I am generating a link-report from the main 
> application, and then using load-externs on the module's compile.
>
> 1) I load up an instance of the module, and it retrieves data just fine.
> 2) I load up a second instance of the same module, but when the data is 
> returned, I get errors relating to the fact it's trying to set my data 
> response to a local VO Class which has already been instantiated from the 
> first module call.
>
>
> I know I've got a shared code issue going on here, but can't figure this out. 
> I've tried the following:
>
> 1) Placed all re-used VO files inside main application, generated 
> link-report, and referenced that link-report via load-externs on the modules 
> compilation then I set applicationDomain on module load to be 
> Application.currentDomain.
>
> 2) Placed all VO files inside module where they are actually used, and then 
> set applicationDomain to a "new ApplicationDomain()" instance to try and 
> sandbox their use.
>
>
> Neither of these worked which is suffice to say, why this post is being 
> written.
>
>
> Thanks in advance for help.
>
>
> Brendan
>

[flexcoders] Re: Duplicate Module Loads - applicationDomain / Shared Code Issues

2009-05-17 Thread Brendan Meutzner 
Alex,

That definitely did the trick.


However...

I'm using DataService calls inside the modules, and now when event listeners 
get set for result/fault/conflict events on them, they carry over to the other 
modules.  So if I open module 1, load it up and make a data call, then load 
module 2, the result event on module 1 & 2 get fired.  I can't exactly remove 
the event listeners on these (which would be the simplest answer) because of 
the fact that data synchronization is happening through LiveCycle DS.

I have yet to look into trying to identify the calling module which causes the 
result event to see if I can single them out and ignore other multiple 
instances (which I will do tomorrow), but thought I'd post to see if there was 
an easier solution.

Thanks very much for your original answer on this... it really helped out :-)


Brendan



--- In flexcoders@yahoogroups.com, Alex Harui  wrote:
>
> In theory, you simply put all shared VO’s in the main app and don’t mess 
> with applicationDomains.
> 
> Also in theory, if it is the same module class there is no need to load it 
> twice, you should instantiate it twice (via factory.create()) and pass it 
> parameters it needs to make different backend calls.  Should take less memory 
> this way, and might avoid this shared code issue.
> 
> Modules don’t work if you use “new ApplicationDomain()” as there must 
> be shared interfaces between the loader and loadee, and using 
> applicationDomain.currentDomain will lock the module into memory.
> 
> Alex Harui
> Flex SDK Developer
> Adobe Systems Inc.
> Blog: http://blogs.adobe.com/aharui
> 
> From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On 
> Behalf Of Brendan Meutzner
> Sent: Saturday, May 16, 2009 3:48 PM
> To: flexcoders@yahoogroups.com
> Subject: [flexcoders] Duplicate Module Loads - applicationDomain / Shared 
> Code Issues
> 
> 
> 
> 
> 
> Hi All,
> 
> I'm having trouble wrapping my head around an issue I'm facing while loading 
> the same module twice into my main application.
> 
> I've got a module which takes a few arguments to load up property data.  If I 
> ask for a different set of data, the same Module class gets loaded, it just 
> makes different back end calls to populate its data.  My module is located in 
> a different project from my main application, so optimizing to application 
> isn't an option.  However, I am generating a link-report from the main 
> application, and then using load-externs on the module's compile.
> 
> 1) I load up an instance of the module, and it retrieves data just fine.
> 2) I load up a second instance of the same module, but when the data is 
> returned, I get errors relating to the fact it's trying to set my data 
> response to a local VO Class which has already been instantiated from the 
> first module call.
> 
> 
> I know I've got a shared code issue going on here, but can't figure this out. 
>  I've tried the following:
> 
> 1) Placed all re-used VO files inside main application, generated 
> link-report, and referenced that link-report via load-externs on the modules 
> compilation then I set applicationDomain on module load to be 
> Application.currentDomain.
> 
> 2) Placed all VO files inside module where they are actually used, and then 
> set applicationDomain to a "new ApplicationDomain()" instance to try and 
> sandbox their use.
> 
> 
> Neither of these worked which is suffice to say, why this post is being 
> written.
> 
> 
> Thanks in advance for help.
> 
> 
> Brendan
>