Joe, You make some great points, that we have already discussed in detail internally; it's fair to say that we're no longer "eating our own dog food" with regards to View Helper.
What we currently have in Cairngorm 0.9 is a good practice we believe, but like you, we also are now more comfortable with allowing data-binding to assume some of the responsibility for model-view coupling. Rather than just throw this into Cairngorm, we were anxious that any architectural best-practice we promote actually be road-tested in a real Flex delivery; we've put our thinking into a current project that is near delivery into test, and we're VERY happy with the implementation. So ... in the weeks ahead, we'll perhaps unveil the strategy that will make it into Cairngorm 1.0; for those using ViewHelpers that are happy with the current abstraction, everything will continue to work just fine with Cairngorm 1.0 as it does with Cairngorm 0.9. 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). View Helpers will then reclaim their rightful place, as "preparing the model for the view" rather than "manipulating the view". 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. You favour the latter, which puts you on the winning side at iteration::two right now :-) As soon as I get some free time I'll post something to Flexcoders, either in concert or in advance of the Cairngorm 1.0 release. 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. Best wishes, Steven > -----Original Message----- > From: Joe Berkovitz [mailto:[EMAIL PROTECTED] > Sent: 07 March 2005 17:14 > To: [email protected] > Subject: [flexcoders] Design point: View Helpers vs. data binding > > > Hi all, > > I've been reviewing the Cairngorm app framework, and I find > many things to like. The notion of ViewHelpers is a bit > problematic to me, however. > I'm sure that this forum contains folks with some > enlightening opinions on that subject, though... including > iteration::two themselves, of course... > > From the API docs: > > In order to carry out their function, Command classes will > require to > both interrogate and update the view. Prior to > performing any > business logic, the Command class may > require to fetch values that > have been set on the view; > following completion of any business > logic, the final task > often to be performed of a Command class is to > update the > View (user interface) with any results returned, or > > perhaps to switch the View entirely (to a different screen). > > > > By encapsulating all the logic necessary for interrogating > and > updating a particular View into a single helper class, > we remove the > need for the Command classes to have any > knowledge about the > implementation of the View. The > ViewHelper class decouples our > presentation from the > control of the application. > > I'm fully signed up for "decouples presentation from control" > :). My issue is with the way in which this is done, and how > it's described. > > ViewHelpers apparently act as encapsulations of view logic, > as seen from the perspective of a Command (which I think of > as having a business-logic or model-like character). This > appears to require the hardwiring of awareness of views (or > at least, of names for them and methods that their helpers > surface) into Commands. Shouldn't a Command just do what it > needs to do, without worrying about the presentation layer? > > More concretely, in your sample app, when > LoginCommand.onResult() calls: > > var demoViewHelper = /* obtain view helper from locator */; > demoViewHelper.switchToMainView(loginDate) > > this feels like a level of view awareness that LoginCommand > has no right to have. It also means that the view no longer > declares what state it depends on (a great benefit of data > bindings) -- one must inspect all Command code to find out > what changes might perturb the view. > > I would feel so much more comfortable with something like: > > var sessionState = /* obtain session state model from locator */; > sessionState.loggedIn = true; > > Then the DemoView can employ a data binding on the loggedIn > property of sessionState, or add an event listener, in order > to trigger a switch. > > Perhaps I've missed some discussion points that have already > flown by in the group, or have some basic misunderstanding; > please excuse me if that's the case! > > . . . . ...j > > Joe Berkovitz > Allurent, Inc > 30 Brattle St. > Cambridge, MA 02138 > > > > > > Yahoo! Groups Links > > > > > > > --- > > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.853 / Virus Database: 581 - Release Date: 01/02/2005 > >
