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: [email protected] >To: [email protected] >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 [email protected], "ben.clinkinbeard" ><[EMAIL PROTECTED]> wrote: > > > > I'm pretty sure they're called ValueObjects for a reason :) > > > > Ben > > > > --- In [email protected], "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 [email protected], "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/
