As I said, we're still doing textbook Cairngorm. My question revolved around our extract class refactoring that we started.
Also, there's nothing that I'm aware of that says everything in the model has to be a VO. We still use VOs exclusively for moving data between different layers of the app. thanks --- In flexcoders@yahoogroups.com, "Darren Houle" <[EMAIL PROTECTED]> wrote: > > Okay... well... that sounds nice, but... your subject for this thread was > "Some Cairngorm questions" and what you're doing doesn't sound much like > cairngorm, so... I guess a more approrpiate subject might have been "Here's > how we've changed Cairngorm into a different pattern, and why." > > Just kidding :-) :-) :-) > > Sounds like you've got something that works for you, and that's what counts! > > Darren > > > >From: "jrjazzman23" <[EMAIL PROTECTED]> > >Reply-To: flexcoders@yahoogroups.com > >To: flexcoders@yahoogroups.com > >Subject: [flexcoders] Re: Some Cairngorm questions > >Date: Sat, 19 Aug 2006 15:40:41 -0000 > > > >Our VO classes are separate from the model. We found that the model > >needed stuff that didn't belong in the VOs, for example, fields that > >don't get persisted to the db, state variables, and various methods > >that the classes in the model need. When we do need a VO to pass to > >the data layer, we call toVO(), which, you guessed it, gives us a > >plain ol' VO. We didn't get too far into our project before we > >realized that model != VOs. > > > >The code that knows what parts of the model need to be persisted, and > >when and how to do it is in a separate utility class that we call a > >persistence manager. It has all the logic that was cluttering up the > >Commands. Now the command just uses the persistence manager in a very > >simple way, like pm.saveCar(car). So each command is back to fitting > >one screen, which I think is nice. > > > >Jeremy > > > >--- In flexcoders@yahoogroups.com, "ben.clinkinbeard" > ><ben.clinkinbeard@> wrote: > > > > > > I'm pretty sure they're called ValueObjects for a reason :) > > > > > > Ben > > > > > > --- In flexcoders@yahoogroups.com, "Darren Houle" <lokka_@> wrote: > > > > > > > > >As for reusing events and commands from different places, most of > >what > > > > >I could find from the Cairngorm creators suggest that Commands be > > > > >specific use cases and a Command should always know its context. I > > > > >suppose if the event payload indicates the context, then you're not > > > > >violating this rule. I hadn't thought about doing this. > > > > > > > > I take Steven literally when he says Cairngorm should be a > >lightweight > > > > framework :-) > > > > > > > > > > > > >By "something else" I was referring to something other than a Command > > > > >(say, a model object) consuming the Delegates. Anything wrong with > > > this? > > > > > > > > So... you're saying that, for instance, a User vo stored in the Model > > > > Locator would not only describe User data fields, but also contain > > > methods > > > > with business logic? Like methods that could create delegates and > > > deal with > > > > the returned results? It's not OOTB, so I'm not sure it's > > > "Cairngorm" but > > > > it's not against the laws of the universe either, it could work. > >There > > > > *are* examples of vo's out there that do things like track and > > > increment a > > > > static emp_id, or populate new vo properties in the vo constructor > >with > > > > values based on some other value stored in the Model Locator, but > > > I'm not > > > > sure I'd put alot of business logic in there for several reasons; > > > other > > > > developers familiar with Cairngorm wouldn't think to look for that in > > > > there... you'd have to change the Front Controller, Commands, and > > > Delegate > > > > around... and you'd also be storing business logic inside your data > > > model, > > > > which to me would make me feel all itchy. > > > > > > > > I think limited logic in the vo's, used to intelligently construct > > > that vo, > > > > would be cool, but I'm not sure I'd expect to see much else in there. > > > > > > > > Darren > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >--- In flexcoders@yahoogroups.com, "Darren Houle" <lokka_@> wrote: > > > > > > > > > > > > Jeremy... > > > > > > > > > > > > > > > > > > >First. I don't see what value the FrontController adds in Flex > > > apps. > > > > > > > My initial thought was that it was important to prevent views > > > from > > > > > > >coupling to specific commands. > > > > > > > > > > > > Yes, if you subscribe to the idea of an MVC pattern then yes, you > > > > >need to do > > > > > > this. And if you're not going to do this then you should either > > > > >design a > > > > > > better pattern... or don't use one at all... but don't code > > > > >something that's > > > > > > only half Cairngorm. Mostly because if I'm the developer who > >comes > > > > >after > > > > > > you and has to reverse-engineer your code one day I'd like to know > > > > >where > > > > > > things are and not have to quess or re-write it all from > >scratch :-) > > > > > > > > > > > > > > > > > > >That really doesn't hold up though, > > > > > > >because the views are coupled to specifc events > > > > > > > > > > > > Yes, Views generate events, but they don't have to be specific, > > > like: > > > > > > > > > > > > AddPublicUserToManagerList(user) > > > > > > > > > > > > they can be generic, like: > > > > > > > > > > > > AddUserToList(user, "public", "manager") > > > > > > > > > > > > That way several different Views can re-use an Event and your > > > > >Command can > > > > > > figure out what it should do based on the event args. There's > > > pros and > > > > > > cons, but that's one way to reduce the number of pieces and parts. > > > > > > > > > > > > > > > > > > >each of which results in a specific Command being executed. > > > > > > >Since the FrontController > > > > > > >maintains a 1-to-1 map of Cairngorm events to Commands > > > > > > > > > > > > Not necessarily. Yes, they are normally 1 to 1, but if you > >want an > > > > >Event to > > > > > > trigger two Commands you can also do this in the Front Controller: > > > > > > > > > > > > addCommand(AppController.EVENT_ONE, SomeCommand); > > > > > > addCommand(AppController.EVENT_ONE, AnotherCommand); > > > > > > > > > > > > > > > > > > >why don't views just run the commands directly? > > > > > > > > > > > > You could, and it's not a terrible thing to argue for fewer > >pieces, > > > > >like for > > > > > > instance Delegates are actually optional, but they do help during > > > > >testing > > > > > > and development because it's easier to point a simple Delegate > >at a > > > > >test > > > > > > Service than to find and re-point all the occurances of a > >Service in > > > > >your > > > > > > Commands. So, yes, you could do without the Front Controller > >but by > > > > >gaining > > > > > > simplicity you'd lose some flexability (as well as confusing > >another > > > > > > Caringorm developer who's pulling their hair out trying to find > > > > >where you > > > > > > put your Front Controller.) > > > > > > > > > > > > > > > > > > >Next, we're moving most of our remote object calls into the > >model. > > > > > > >The logic that controls what parts of the model get persisted, > > > when, > > > > > > >and in what order is complex, and our Commands had become > >huge and > > > > > > >full of logic. As a reuslt of the changes, lots of the classes > > > in the > > > > > > >model now make remote calls and implement IResponder. I'm > > > trying to > > > > > > >get back to the model of Command kicks off the "feature" and > > > then gets > > > > > > >out of the way. Is there any rule with Cairngorm that says that > > > > > > >Commands must do the remote calls? Is it common to use something > > > > > > >other than a Command to make remote calls? > > > > > > > > > > > > Do you mean "something else" making the call to the Service as > >in a > > > > > > Delegate, or do you mean some other class (maybe a subclass of > > > Command) > > > > > > handling that? As far as vanilla Cairngorm goes there's > >really just > > > > > > Command, SequenceCommand, and Delegate. I'm pretty sure, > > > though, that > > > > > > Adobe/Steven feel Cairngorm is a starting point to be built > >on... so > > > > >if you > > > > > > stick to the basic pattern but need to add to it then that's > >totally > > > > >cool. > > > > > > I actually find that you almost *have* to expand on Cairngorm > >to get > > > > >certain > > > > > > things done... like running a Command that's dependant on another > > > > >Command > > > > > > that's dependant on the results of a WebService call that's > > > > >dependant on the > > > > > > results of another WebService call. Complicated business > >logic may > > > > >require > > > > > > custom pieces be added to the base, but that's an okay thing. > > > > > > > > > > > > Darren > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-- > > > > >Flexcoders Mailing List > > > > >FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > > > > >Search Archives: > > > http://www.mail-archive.com/flexcoders%40yahoogroups.com > > > > >Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-- > >Flexcoders Mailing List > >FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > >Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com > >Yahoo! Groups Links > > > > > > > > > > > > > -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
