Hey Scott, Here's some feedback on your points:
> - formalised approach to command subscriptions, in that a controller > is established which registers itself against commands for both Views > and Models - but in a relatively simplified syntax (ie addCommand) A simple controller would have been a singleton with a big case statement to handle various events. As an itch in your OO design gland is no doubt warning you case statements are a clarion call to refactor, which the i2 guys did with the "command" pattern to split each case out into a separate class. When you add a command this limits the change to the controller to a single addCommand call in the constructor, and keeps the controller nice and small. The other advantage of separate command classes is that the when you make a remoting or webservice call the result and fault handlers can be methods of each command class - if you hadn't split commands out into separate classes you would need big case statements inside onResult and onFault handlers, which would have seen you in emergency with a severe allergic reaction. > - Seperating ViewPods from logic via "ViewHelpers". It appears that > the framework allows a developer to add "behaviours" or "logic" to a > view but in a way that its not coupled with that said view (ie i > assume you could add a ViewHelper to other ViewPods? - yet all feed > off the one instance/codebase). To me view helpers are about minimising the control logic's (Commands are part of the control logic) exposure to the view - up in the control layer you want to keep things at the "sentance-in-a-use-case" level i.e. promptUserLogin() and not sink into showPopupLoginPanel(). The view helper method names use a control layer vocabulary but their implementations are very view-aware. So the view helper provides a service to the control layer, not to the views themselves. I've never called a view helper from a view, I'm not clear what the Cairngorm position is on doing that, and as yet I haven't used view locators. There have been a few discussions about how thick view helpers should be, I think the most recent statement was that the helper should allow the control layer to set the model being used by the views and not much else. > - Templated Command Objects : it seems to me that the whole Command > concept has established a base template to work from, so that > onResult, onFault and execute are automatically invoked per command? - > then the developer can just fill in the blanks based on the event > type? execute() is the only method required by the Command interface - this interface is the contract a Command has with the controller to handle events forwarded to the Command. If your command calls business delegates or any class that requires onResult() and onFault() callbacks (not all do) it implements the Responder interface. Note that there isn't really a neat solution yet for commands that need to call multiple delegates - look back through the list for some discussions on this, Steve has something up his sleeve for 1.0 I think. In the meantime you can daisy-chain commands together by broadcasting a new event in the first command's onResult, or risk the rash and do a case statement. > - ViewLocator - kind of reminds me of DHTML's > document.getElementById() in that it appears each ViewHelper registers > itself within cairngorm and the ViewLocator simply provides a dynamic > bridge between the actual view and the object requesting its location? > or something like that? ViewLocator, ServiceLocator and EventBroadcaster are basically just lookup services that return singleton instances of view helpers, services and the object the controller listens to for events. Just a bit nicer than writing _global.myService or whatever - which you could do if you really wanted to. HTH Robin --Apple-Mail-54--342723534 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Hey Scott, Here's some feedback on your points: <excerpt> - formalised approach to command subscriptions, in that a controller is established which registers itself against commands for both Views and Models - but in a relatively simplified syntax (ie addCommand) </excerpt> A simple controller would have been a singleton with a big case statement to handle various events. As an itch in your OO design gland is no doubt warning you case statements are a clarion call to refactor, which the i2 guys did with the "command" pattern to split each case out into a separate class. When you add a command this limits the change to the controller to a single addCommand call in the constructor, and keeps the controller nice and small. The other advantage of separate command classes is that the when you make a remoting or webservice call the result and fault handlers can be methods of each command class - if you hadn't split commands out into separate classes you would need big case statements inside onResult and onFault handlers, which would have seen you in emergency with a severe allergic reaction. <excerpt>- Seperating ViewPods from logic via "ViewHelpers". It appears that the framework allows a developer to add "behaviours" or "logic" to a view but in a way that its not coupled with that said view (ie i assume you could add a ViewHelper to other ViewPods? - yet all feed off the one instance/codebase). </excerpt> To me view helpers are about minimising the control logic's (Commands are part of the control logic) exposure to the view - up in the control layer you want to keep things at the "sentance-in-a-use-case" level i.e. promptUserLogin() and not sink into showPopupLoginPanel(). The view helper method names use a control layer vocabulary but their implementations are very view-aware. So the view helper provides a service to the control layer, not to the views themselves. I've never called a view helper from a view, I'm not clear what the Cairngorm position is on doing that, and as yet I haven't used view locators. There have been a few discussions about how thick view helpers should be, I think the most recent statement was that the helper should allow the control layer to set the model being used by the views and not much else. <excerpt>- Templated Command Objects : it seems to me that the whole Command concept has established a base template to work from, so that onResult, onFault and execute are automatically invoked per command? - then the developer can just fill in the blanks based on the event type? </excerpt> execute() is the only method required by the Command interface - this interface is the contract a Command has with the controller to handle events forwarded to the Command. If your command calls business delegates or any class that requires onResult() and onFault() callbacks (not all do) it implements the Responder interface. Note that there isn't really a neat solution yet for commands that need to call multiple delegates - look back through the list for some discussions on this, Steve has something up his sleeve for 1.0 I think. In the meantime you can daisy-chain commands together by broadcasting a new event in the first command's onResult, or risk the rash and do a case statement. <excerpt> - ViewLocator - kind of reminds me of DHTML's document.getElementById() in that it appears each ViewHelper registers itself within cairngorm and the ViewLocator simply provides a dynamic bridge between the actual view and the object requesting its location? or something like that? </excerpt> ViewLocator, ServiceLocator and EventBroadcaster are basically just lookup services that return singleton instances of view helpers, services and the object the controller listens to for events. Just a bit nicer than writing _global.myService or whatever - which you could do if you really wanted to. HTH Robin --Apple-Mail-54--342723534--
<<inline: image/gif>>
On 17/03/2005, at 1:35 PM, Scott Barnes wrote: > I'm currently getting ready to begin a long journey in FLEX > development for a bunch of systems here at work. --Apple-Mail-55--342723533 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII On 17/03/2005, at 1:35 PM, Scott Barnes wrote: <excerpt><x-tad-smaller>I'm currently getting ready to begin a long journey in FLEX</x-tad-smaller> <x-tad-smaller> development for a bunch of systems here at work.</x-tad-smaller></excerpt> --Apple-Mail-55--342723533--
