Title: Why not using Event System for the Delegates? Post by: Oscar on December 21, 2007, 05:49:07 Hi,
sorry it's maybe Offtopic, but why you are not using Events for the Delegate? For example in the "ApplicationSkeleton" (http://forums.puremvc.org/index.php?PHPSESSID=da7f0182d00846b60d9071fc0dc45469&topic=21.0) App. In the Class "ResourceProxy":
Why not making use of Events here, like for example this:
The Cairngorm (http://www.cairngormdocs.org/tools/CairngormDiagramExplorer.swf) Framework also not using Events for the Delegates. Click on the "CMD" and "Business Delegate" Symbol, to see the Code below. It seems, there must be a reason, don't using Events here. But why not? Title: Re: Why not using Event System for the Delegates? Post by: cliffrowley on December 21, 2007, 01:19:11 I would hazard a guess and say that this is for the same reason that PureMVC uses Notifications rather than Events - to remain completely platform agnostic. The Event mechanism is a Flash/MX'ism and depending on it ties PureMVC down to a specific implementation.
Title: Re: Why not using Event System for the Delegates? Post by: puremvc on December 25, 2007, 09:21:08 Actually, it's perfectly fine to add event listeners to boundary objects on the Model side just as we add event listeners to the UI components on the View side. There is another reason for Delegates to be designed the way they are, regardless of what framework they're being used with.
For discussion: here's the body of the LoadXMLDelegate as it is in the repository at the moment: The Delegate's responsibility is limited to making the service call. Any number of callers may invoke the service, and the results may come back in random order. Therefore simply adding a listener to this component would not work. You still need to sort out which listening component needs to respond to a given result or fault. Instead, the caller is added as a 'responder' on the unique AsyncToken for the service invocation. This allows the appropriate responder to be called for each service result (or fault). The caller must implement mx.rpc.IResponder, a Flex interface, insuring it has the right callback methods. When the service returns, it will be called on its result or fault method. This does tarnish your Proxy a bit; making it implement a Flex interface keeps it from being easily portable to say, Flash or Silverlight. However, the business of making the call without the Flex classes would require us to figure out all the nice stuff that mx.rpc classes give us. -=Cliff> |