However, we'll also be advocating an architecture that uses binding and view helpers in unison, to achieve a much cleaner decoupling of model and view, and a more classic "MVC" object listening/notification model (that binding gives us).
Sounds good to me!
Your post suggests that you would be happier with state being held in the model as well; this is the one remaining topic of discussion within iteration::two - whether we're happy for the Command classes to dispatch the view (as we would previously have done with RequestDispatcher in a J2EE Command class implementation using Servlet/JSP) or whether the view should render itself according to the state held in the model.
I consider the typical use of RequestDispatcher (or ActionForwards in Struts) to be an unpleasant artifact of the request/response model, not a good pattern for RIAs. (As a side point, I'm a bit uncomfortable with taking so many cues from J2EE design patterns; they're anything but gospel in the RIA domain.)
Here are a couple approaches that I think are reasonable (since I don't like Commands dispatching views, as you might guess :)
- The view renders itself according to the model state, using data bindings to trigger changes. Insofar this involves switching from one view to another, some sort of fairly generic adapter object can intercept model state changes and control a ViewStack appropriately, etc. etc. This object would be constructed by the presentation layer and bound to the model state; it has no need to be in the view adapter namespace.
- Some sort of centralised navigation service exists, with a declarative model (FSM-like?) of allowable nav states. Commands may indicate a change in navigation state, but do not know what that means in terms of presentation side effects. The presentation layer registers components with this service to be hidden or shown as per the declarative model. This is really just a variation of the above idea, but with much more meat in the "adapter" part.
Personally I favour the first approach, as it's simpler and we don't have enough use cases to drive the second, though it might in the long run deliver more value to developers.
Glad to see we're alike in our preferred strategy .. makes me feel comfortable that we have in fact hit on a satisfactory implementation of the patterns for Flex.
Look forward to the continuing discussion here!
FWIW, we're currently using our own proprietary framework that (not surprisingly) turned out to overlap what we've seen from Cairngorm so far. This is mostly about controlling our own near-term destiny and codebase, not so much about staking a claim in the framework space. We'll probably keep going down that path, but I want to share broad architectural observations with this group, and would love to contribute as much as possible to the development of useful patterns and a concensus on how best to use them. I think Cairngorm, ARP, and so on are an incredibly helpful set of initiatives for all RIA developers, whether they're actively using them or just thinking about the best way to do things.
Regards...
. . . . ...j
