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
