I think the problem is that the current flex framework architecture doesn't conceptually work well with Cairngorm. There's too much logic encapsulated into the view.
Ideally you would like to drive the entire app via the model. It would be ideal if your model was managing how many windows are currently open and therefore knows which data models to tear down. --- In flexcoders@yahoogroups.com, "Ben Clinkinbeard" <[EMAIL PROTECTED]> wrote: > > You definitely don't want your model keeping track of views using its data. > My 30 second recommendation would be to look into the UM Cairngorm > extensions as they can help you reduce the amount of clutter that needs to > be stored on the/a model. Specifically view callbacks is the feature that > helps enable that. Search flexcoders for additional discussion of UM > Cairngorm. > > HTH, > Ben > > > On Tue, Apr 29, 2008 at 12:24 PM, gerhard.schlager < > [EMAIL PROTECTED]> wrote: > > > Hello! > > > > I'm currently creating the software design for a large application > > which we are going to build using Flex 3, Cairngorm 2.2.1 and SabreAMF > > (PHP). I have already created my first prove of concept, however, I > > have a few issues with Cairngorm's Model Locator. > > > > 1) How can I make sure that unused data gets removed from the Model > > Locator? The simple solution would be to destroy the data that a view > > loaded when the view gets closed. However, we are going to use flexmdi > > and it's quite possible that one or more MDI windows are using the > > same data. The only solution I've come up so far is to make the Model > > Locator aware of which window uses which data. Therefore it could free > > the unused data when no view uses it anymore. Yet, this could be a > > very error-prone solution. Moreover, I would loose the last bit of > > loose coupling. So, I'm not sure if that's a good way to handle this. > > Well, the Model Locator itself is often seen as an anti-pattern as > > well ... > > > > 2) Should I really put everything into _one_ Model Locator? I guess > > there could be quite a large number of public variables. Our > > application will have up to 50 different views and about twice as many > > VO ... > > > > I'd be really grateful if somebody could enlighten my ;-) or if you > > could give me some tips on how to solve those two problems. > > > > Thanks in advance for your help. > > > > Best regards, > > Gerhard > > > > > > >
