Hey Michael, > In my application when a product has been added, I wish to broadcast a > "product added" event and have it picked up by two separate > command classes that will update two separate views. Unfortunately, when > the event is broadcast, it only seems to be picked up by the command class
> that was registered last in the controller. Without having looked at the implementation since your email, it sorta kinda makes sense right now that the "last registered command" would be the one that responded. If we wanted to be able to have multiple commands execute on the same event, then I'm sure we could accomodate that (we'd have to register lists of commands rather than commands themselves - no biggie). However, I think there's a whiff of a bad smell here.... > To get round this I am having to broadcast two separate > events specific to the two views once a product has been added. > Obviously, this doesn't provide as high a level of de-coupling > as I would like. So if I understand this correctly, your workflow is as follows.... ...on successful completion of a command you want your view to update in 2 different places, and you could achieve that by calling on 2 different commands ? Correct ? Really, what I'd hazard you to be thinking about, is that instead of broadcasting the "fork event" (the one that executes 2 commands) you should be updating a model on your application. In turn, your different views should be bound to that model, and should update themselves automatically (via binding) when the model is changed. The waters are muddy with view helpers; while commands can employ view helpers to update the view, the real motivation for the view helper pattern is to "prepare the model for the view", ie to format the model in some way before it is rendered. It can be a useful pattern for simply keeping view management out of your commands, but I think you're hitting a place where the strategy isn't so great for you. Currently, we've advocated that you have a single file called State.mxml (much like the Services.mxml) where you keep "global model" as a client-side state (think of it as replacing CFSESSION or an HttpSession in Java). You can bind your views to value objects that reside in State.mxml Does that work for you ? The good news, is that in the soon-to-be-released update to Cairngorm, we've implemented a new strategy that simplifies view management even further for people; it certainly doesn't deprecate anything that people are doing currenlty, but will give you a neat way of wrapping your head around how you should manage complex view as your RIA scales. It's fair to say that myself, Alistair, Dan, Ilya, Romain, Dirk, Jimmy and Matt bounced a number of different strategies around on this one ... to make sure we got the balance right between taking advantage of the heavy-lifting that Flex does for us, and an appropriate degree of encapsulation to fit this neatly and concisely into the Cairngorm-world-view of an application. Ilya coded us up 3 different strategies, and a solution is now in place in the next code-drop. We're using this on some of our own current projects right now, and it's working very well for us. Best, Steven -- Steven Webster Technical Director iteration::two This e-mail and any associated attachments transmitted with it may contain confidential information and must not be copied, or disclosed, or used by anyone other than the intended recipient(s). If you are not the intended recipient(s) please destroy this e-mail, and any copies of it, immediately. Please also note that while software systems have been used to try to ensure that this e-mail has been swept for viruses, iteration::two do not accept responsibility for any damage or loss caused in respect of any viruses transmitted by the e-mail. Please ensure your own checks are carried out before any attachments are opened.
