…since this post was started in the Flex / Cairngorm vein, and I don’t even want to start to ignite the MVC discussion, I’ll go with yup, it does ‘it all comes back to how people think Controller code should be written.’ ;-)

..and yes, I also totally agree with this:

‘modified Commands to have a resultFunction; much like a Delegate, Commands can now call a function in a specific, pre-assigned scope when completed rather than some implied known function on viewRef.’

as I did the same thing. I find myself almost always adding in scope and callbacks (both result and status) to objects that perform services and what not.

[slightly OT]…in fact, speaking of services, I did exactly that for my XMLService object. I found that many clients have been / continue to leverage XML as their data vehicle — even more so now with all the new XML APIs — so I created a an XMLService object that’s modeled after the remoting API for ARP — returns a Result or Fault object. I then added a CSSService and LoadVarsService object as well. Mind you, I did this for ARP and haven’t decided if necessary or warranted in Cairngorm.

…sorry, I realize this was slightly off-topic, but I’ve also been engulfed with the new additions to ARP 3 that Aral’s suggesting, and thus, I’ve been just waiting to dive into the future framework as well as hear what everyone thinks…to that, it’d be interesting to know if Aral’s planning on an AS2 and AS3 vr of ARP3…

I’ll end with, runtime type checking…good schtuff.

To me, the Commands in Cairngorm have context based on how they are supposed to run based on the event it gets in the execute function. This event has the data you passed it from the event. So, technically, it is a roundabout way of doing my change to ARP of CommandRegistry; allowing the Application more control over the context in which a command runs. So, yes, Aral even suggested I relax, and use handleEvent since I can intercept any event, and handle as I please. In ARP, that felt too limiting, hence my need for a Command to have a result handler to call vs. having it update data itself, or use a ViewHelper. Instead, I wanted to let the Application handle context. This leads in nicely to chaining commands. I’m aware Cairngorm already has this, but I dig all of that happening in the Application.

In Cairngorm, I’m still getting used to ‘Hey command, here’s your context in which to run based on the data I passed in as the 2nd parameter to the event.’ Does it work by design? Sure. I guess I just feel uncomfortable passing arbritary/vanilla objects that they themselves have context. For example, ActionScript 3 encourages the events be actual classes that extend flash.display.Event. This allows great context to the restult handlers who handle the events since the events have strict-typing on the data they have, and there is no misunderstanding on the context of the event. If there is, you get a runtime exception.

However, in retrospect, it’s totally cool. We have a somewhat strictly typed language that’s easily hacked around, and Cairngorm is at version 1, Flex at 1.5. So, again, I retierate I love ’em (the frameworks), and can’t live without them. I just think there is tons of room for improvement which ActionScript 3 will help with a lot. From a theory perspective, the ViewHelper vs. View -> bind to ModelLocator is already promoted. It all comes back to how people think Controller code should be written which is a varied topic.

i’m neither using Caingrom, nor Arp on an everyday base, but to me the split between View and ViewHelper is very useful. I like to keep my views as dump as possible. All they contain is setter/getters for the data to display and maybe they emit some events, if it is an interactive view, but nothing more. If i want to test this view, i don’t need the whole framework to work, but just a little dummy class, which calls the setters with some fake data. On the other hand, if i need to test the rest of the application, i can simply replace the view with a dummy, which does automatically, whatever i want to test.

So what the helper basically does, is separating two subsystems.

Cheers,
Ralf.