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

2009-05-18 Thread Amy
--- In flexcoders@yahoogroups.com, Alex Harui aha...@... 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,

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 aha...@... 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: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





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.commailto:flexcoders%40yahoogroups.com, Alex 
Harui aha...@... 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.commailto:flexcoders%40yahoogroups.com 
 [mailto:flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com] On 
 Behalf Of Brendan Meutzner
 Sent: Saturday, May 16, 2009 3:48 PM
 To: flexcoders@yahoogroups.commailto: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,

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 aha...@... 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.commailto:flexcoders%40yahoogroups.com, Alex 
 Harui aharui@ 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.commailto:flexcoders%40yahoogroups.com 
  [mailto:flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com] On 
  Behalf Of Brendan Meutzner
  Sent: Saturday, May 16, 2009 3:48 PM
  To: flexcoders@yahoogroups.commailto: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