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 <*> 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/
