Hi asik, there is a workaround for your problem: http://viconflex.blogspot.com/2007/05/loading-multiple-independent-instances.html
Regards, masu On 7/6/07, asik <[EMAIL PROTECTED]> wrote: > > Could you explain : > "We put the Cairngorm framework and all 'core' classes (ie Controller, > ModelLocator, ValueObject, centralized Commands) into a Flex > Library." in little detail? > > I am using cairngorm framework and modules in my project. I am not > able to load two seperate modules as i'm getting an error(multiple > instance of service Instance not allowed.) > > Could your method solve this problem..??? > --- In [email protected] <flexcoders%40yahoogroups.com>, "Dirk > Eismann" <[EMAIL PROTECTED]> > wrote: > > > > I think the two actions Derrick mentions - to use BindingUtils to > remove {} bindings and to use weak reference listeners where > possible - are the two key techniques to limit memory / GC issues. > > > > This is not only something to watch out for when loading/unloading > Modules but also when components get dynamically added/removed inside > a Flex application. > > > > Dirk. > > > > > > -----Ursprüngliche Nachricht----- > > Von: [email protected] <flexcoders%40yahoogroups.com> im > Auftrag von Derrick Grigg > > Gesendet: Di 16.01.2007 15:17 > > An: [email protected] <flexcoders%40yahoogroups.com> > > Betreff: [flexcoders] Re: Cairngorm support for Flex 2.0.1 modules? > > > > My team is currently in the process of developing a large modular > Flex > > application that is based on Cairngorm and uses the mx:Modules. > > > > We put the Cairngorm framework and all 'core' classes (ie > Controller, > > ModelLocator, ValueObject, centralized Commands) into a Flex > Library. > > Each module was setup as a separate Flex project along with a shell > > project that was responsible for loading the modules and creating > the > > basic shell application. Each of the modules accessed the 'core' > > classes as an RSL during development and then the option was set to > > 'external' for deployment to reduce file size and duplication. The > > shell used the 'include' compiler option to compile the > entire 'core' > > library into the shell so that all classes where available for the > > modules. Each module ran a method upon loading that would register > any > > module specific Commands with the FrontController and register for > any > > events, etc. > > > > The one thing that was quite tricky was uncoupling binding from the > > ModelLocator during module unloads. Using the {} method in the > > property attribute of a control (ie <mx:DataGrid > > dataProvider="{model.shoppingList}"/>) does not allow you to > uncouple > > the binding at a later time, which prevents garbage collection. > > Instead we had to use the BindingUtils and then call a method just > > before unloading a module to remove the bindings, then the module > > could be properly unloaded and garbage collected. Also we had to > make > > sure we used weak reference event listeners in order to ensure > garbage > > collection would properly occur on the unloaded modules. > > > > Hope that information helps you out. > > > > Derrick > > ------------- > > Derrick Grigg > > [EMAIL PROTECTED] > > > > > > > > -- > > Flexcoders Mailing List > > FAQ: > http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > > Search Archives: > > http://www.mail-archive.com/flexcoders%<http://www.mail-archive.com/flexcoders%25> > 40yahoogroups.com > > Yahoo! Groups Links > > > > >
