[flexcoders] Re: Some Cairngorm questions
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 - 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
[flexcoders] Re: Some Cairngorm questions
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 [EMAIL PROTECTED] 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
RE: [flexcoders] Re: Some Cairngorm questions
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 - 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 [EMAIL PROTECTED] 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
[flexcoders] Re: Some Cairngorm questions
Ben, Thanks for your viewpoint. I'd like to summarize your points to see if I understood correctly: 1) It's easy to execute a Command by raising a Cairngorm event. It seems to me that the amount of code to raise a Cairngorm event is the same as executing the Command directly. Probably the same # of imports. 2 lines of code to raise a cairngorm event. 2 lines of code to instiate and execute a Command. 2) FrontController keeps instances of the Command in one place. I'm not sure this is technically true. To me, the more imporant thing to control is the various places that you're raising Cairngorm events, which can get messy in a large app. We typicallly try to raise Cairngorm events at the highest level possible in a module. Again, the fact that raising the event is not the absolute direct execution of a Command is almost meaningless. 3) Changing the name of a Command is easy because you only need to edit a line or 2 of code in the FrontController. True. But you're still raising Cairngorm events by name/type. If you rename the Command, you'll most likely want to rename the Cairngorm event type. Now you're back to having to find all the places where you're raising that particular event type. This actually shouldn't be much of an issue due to the fact that Commands are supposed to be context sensitive, i.e. the Command should know what screen/module/component caused it to be executed. Therefore, there are usually a small # of places where any one event type gets raised. This context sensitivity is another way in which application code really isn't abstracted from Commands in a meaningful way. I screwed up on my initial explanation of what we're doing with our model. We're still using Delegates.. no direct calling of remote objects. What we are doing is moving the code that uses delegates from Commands to the Model. Again, the reasoning here is that when you do something like (contrived example here...) car.save(), car being a model object, only the car knows what save() really involves, based on state in car and its various components and logic within the car, etc. So the car needs to use Delegates, implement IResponder (or Responder), etc. I think a big benefit we've received from Cairngorm on our current project is the consolidation of the use cases or features into one place, or one tree on the file systems. This seems to facilitate team development some since there is a single place to go and see what use cases exist. The struggle for us has been keeping the Commands very light, thus our initiative to move the logic and delegate calls from some of the really big Commands into the model. Jeremy --- In flexcoders@yahoogroups.com, ben.clinkinbeard [EMAIL PROTECTED] wrote: While I am sure there are others, the first thing that comes to mind concerning your first question is something I did just the other day. Say you've got a command that you want to execute when you receive data back from a remote call. For debugging or other purposes, you now want to be able to execute that command manually, by clicking a button. Using FrontController and the traditional Cairngorm approach, all you have to do is dispatch the event in the click handler. Without FrontController you have to import, instantiate and call execute() on your Command class. Not to mention you now have instances of your Command class scattered about. Or what if you decide that a Command that is called in various places should be named differently or changed in some other way? Using FrontController you greatly minimize the places in which you need to edit your code. I suppose if you never need to execute the same Command in response to more than one type of event (generally speaking, not Event), then your approach would be fine. As I understand it, Cairngorm generally advocates making remote calls from your delegate classes, not commands. Again, the main advantage I see here is code centralization. You might have five different commands that all need to call the same remote method. If something changes and you need to call that method with different arguments or need to call a different method altogether, using a delegate means you change your code once instead of five times. I am still a relative newcomer to Flex and Cairngorm but the main advantages I've seen and loved so far are the things I've mentioned here; code centralization, defined responsibilities and clear separation of duties for the pieces of your app. Most of the time when I do question a methodology put forth by Cairngorm I simply fall back on the thought that its developers are way smarter and more experienced than myself so they probably have a good reason for whatever they did :) Sorry to ramble, HTH. Ben --- In flexcoders@yahoogroups.com, jrjazzman23 jrjazzman23@ wrote: Hi, I've got a couple of questions on my mind that I'm hoping to get some opinions on... First. I don't see what
[flexcoders] Re: Some Cairngorm questions
We are pretty much sticking to textbook Cairngorm. We all just began to question the FrontController. Most of my MVC experience is with struts, where it seems to make more sense. 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. By something else I was referring to something other than a Command (say, a model object) consuming the Delegates. Anything wrong with this? Jeremy --- In flexcoders@yahoogroups.com, Darren Houle [EMAIL PROTECTED] 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 * 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/
RE: [flexcoders] Re: Some Cairngorm questions
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 [EMAIL PROTECTED] 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
[flexcoders] Re: Some Cairngorm questions
I'm pretty sure they're called ValueObjects for a reason :) Ben --- In flexcoders@yahoogroups.com, Darren Houle [EMAIL PROTECTED] 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
[flexcoders] Re: Some Cairngorm questions
While I am sure there are others, the first thing that comes to mind concerning your first question is something I did just the other day. Say you've got a command that you want to execute when you receive data back from a remote call. For debugging or other purposes, you now want to be able to execute that command manually, by clicking a button. Using FrontController and the traditional Cairngorm approach, all you have to do is dispatch the event in the click handler. Without FrontController you have to import, instantiate and call execute() on your Command class. Not to mention you now have instances of your Command class scattered about. Or what if you decide that a Command that is called in various places should be named differently or changed in some other way? Using FrontController you greatly minimize the places in which you need to edit your code. I suppose if you never need to execute the same Command in response to more than one type of event (generally speaking, not Event), then your approach would be fine. As I understand it, Cairngorm generally advocates making remote calls from your delegate classes, not commands. Again, the main advantage I see here is code centralization. You might have five different commands that all need to call the same remote method. If something changes and you need to call that method with different arguments or need to call a different method altogether, using a delegate means you change your code once instead of five times. I am still a relative newcomer to Flex and Cairngorm but the main advantages I've seen and loved so far are the things I've mentioned here; code centralization, defined responsibilities and clear separation of duties for the pieces of your app. Most of the time when I do question a methodology put forth by Cairngorm I simply fall back on the thought that its developers are way smarter and more experienced than myself so they probably have a good reason for whatever they did :) Sorry to ramble, HTH. Ben --- In flexcoders@yahoogroups.com, jrjazzman23 [EMAIL PROTECTED] wrote: Hi, I've got a couple of questions on my mind that I'm hoping to get some opinions on... 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. That really doesn't hold up though, because the views are coupled to specifc events, each of which results in a specific Command being executed. Since the FrontController maintains a 1-to-1 map of Cairngorm events to Commands, why don't views just run the commands directly? 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? thanks Jeremy -- 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/
