Pass events back CairngormEvent

This should be rather simple and there are a few different ways to solve this problem. The first and probably most obvious is to add a property to the ModelLocator representing the applications state or context. The command handling the event would set the state on the ModelLocator as needed. Each view listening to the event would then simple query the ML and respond where applicable. The second approach would be to simply add a property to the event object itself rather than the ModelLocator, however this is not an ideal solution nor very scaleable as you would not want to couple application state to an event.Another option would be to create seperate result events which would be dispatched back to the views from the command. Each view would only listen to the particular result event of interest. You could also go with Martin Fowlers Presentation Model pattern which provides many benefits, however this would require significant refactoring to your current implementation.

Hope that helps.

Best,
Eric

Hi Eric thanks for the example. I have this working and it's great. I dispatch one event from one view and this result is then listened to by a number of views.

I now have the inverse of the problem. I have a number of the same type of components (an email component that can be customized). I have a number of these for different types of emails. They dispatch the "save email" event. However I now only want the original component to be notified of the result event.

Whats the best way to achieve this?

Thanks for your help

Craig

Sorry to insist, but don't you think this discussion is a bit off topic, since it is about how to use cairngorm, rather than what to do with future versions of cairngorm.

Don't get me wrong, this is all very interesting, but, as Alister suggested, wouldn't Yahoo FlexCoders mailing list be more suited for this ?

Or maybe we should focus on another related question : "how could cairngorm be changed to facilitate the communication between commands and views" ? Or just "what's wrong with current implementation"...

Tomek (and others) : concerning the Presentation Model usage debate, I have started a discussion on my blog, you can find it here :
http://www.dehats.com/drupal/?q=node/48

About its place in the future cairngorm releases, I have created another topic in this forum.

Hi Craig,

agree with David that PM would be an answer. I found usefull passing PM with CairngormEvents to Commands, which in turn update PM properties and this way PM drives its related view, ie. PM could contain status property that could be changed in Commands fault or result methods. I don't instantiate PM in ModelLocator, but try to keep there only application scope data. View scope data, properties I try to keep in PM. When PM needs application scope data, they are injected into PM. Moreover I found usefull solution proposed by Neil Webb, to pass modellocator reference to command in a way described here: http://nwebb.co.uk/blog/?p=168. This way command has reference to both: PM and ModelLocator and moreover ModelLocator is instantiated only once in main application.

Since I just started playing with PM and Cairngorm I'd like to hear your thoughs about that.
TM

Hi Craig,
IMHO your question is related to current cairngorm's usage rather than its future. I think (please correct me if I'm wrong) that the AC way to answer your question would be to introduce the PresentationModel pattern.
In your example, your view would have a corresponding PM which would be responsible for dispatching the event. The command triggered by the event would, as usual, update the domain model following to the BusinessDelegate/Responder action. Then, if needed, it could also update the PM. As the view observes its PM, it can be updated accrondingly.
The question is, how does the command access this PM? One possibility would be to do so through the ModelLocator. You can also imagine passing the PM in the event. If more decoupling is needed, it could be done via an interface.

This raises another question : should cairngorm 3 implement in some way the PresentationModel pattern? and how? But I guess this is for another post ;)

Hey Robin,

I think this is more of a design decision than a Cairngorm issue.

An example of where an Event could be re-dispatched to the view for additional view processing would be where some sort of complex view logic / item rendering is needed whereas you may want a bit more control then the framework renders provide. ChangeWatcher could just as well be used to monitor changes in the model of course, and invoke a function to do the same. What I prefer about the re-dispatching of the result/fault event is that Model changes could be made in the command's result and fault as they normally would, however it also allows views to capture additional data which need not be placed on the ModelLocator, an example could be a fault in which an exception Id from the server needs to be displayed in a notification popup etc.

I think an ideal solution would be to provide an interface which the ModelLocator would implement to manage listeners globally for all model properties, via ChageWatcher. What I am not comfortable with (IMHO) from my own experiences is when there are multiple developers handling model changes in different ways as it becomes hard to test but even worse, an inconsistant design.

I think some sort of ModelWatcher object or a ModelHelper or something to that extent would be helpful as it would limit all of the ChangeWatcher instances littered throughout the views and provide a central location for managing and testing model changes. I am interested in hearing everyone's thoughts on this.

Best,
Eric

Hi Craig and Eric,

| however view bindings will not suffice.

Can you give an example of when they wouldn't suffice - in this example of a login we'd usually have some session property in the model that would change from null to something - it's easy to tie a view state to this or fire a handler function using ChangeWatcher.

Firing events for views to pick up is certainly neat but it makes me a little uneasy - if the state of the app has changed IMHO it's important to have some permanent relic left in the model. The advantage of updating the model in the case of the login for instance, is that if a component is instantiated long after the login event has fired, it can still tell that the app is in a logged-in-state by checking or binding to the model.

Cheers,
Robin

Hey Craig,

The way I prefer to handle this is to take advantage of native Cairngorm Event dispatching rather than observers and ChangeWatchers.

For example, let's consider the typical Login example. Imagine you want a view or multiple views to react to the result of a successful login, however view bindings will not suffice. The way to handle this is simple, re-dispatch the event back to the view. Your views can add a listener to CairngormEventDispatcher for that event and simply respond to it. Take a look at Fred Stangls example: http://tech.groups.yahoo.com/group/cairngorm-documentation/message/221

I have also created an interface which can be implemented to facilitate this as well, IViewNotifierEvent:
http://code.ericfeminella.com/classes/as3/IViewNotifierEvent.as.html

Hope that helps.

Eric