The whole point of MVC is that the model knows *nothing* about the view. Which is one of the reasons UM is a great extension to Cairngorm.
-J On Wed, Apr 30, 2008 at 8:46 AM, Bjorn Schultheiss < [EMAIL PROTECTED]> wrote: > 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 <flexcoders%40yahoogroups.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 > > > > > > > > > > > > > > -- "Therefore, send not to know For whom the bell tolls. It tolls for thee." :: Josh 'G-Funk' McDonald :: 0437 221 380 :: [EMAIL PROTECTED]
