Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Why not using Event System for the Delegates?  (Read 7857 times)
Oscar
Jr. Member
**
Posts: 12


View Profile Email
« 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" App.

In the Class "ResourceProxy":
:

...

var delegate : LoadXMLDelegate = new LoadXMLDelegate(this, url);

...

Why not making use of Events here, like for example this:

:

var delegate:LoadXMLDelegate = new LoadXMLDelegate(url);
delegate.addEventListener(LoadXMLDelegate.LOADCOMPLETE, result);

The Cairngorm 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?
Logged
cliffrowley
Courseware Beta
Newbie
***
Posts: 2


View Profile Email
« Reply #1 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.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #2 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:

:

/*
 PureMVC AS3 Demo - Flex Application Skeleton
 Copyright (c) 2007 Daniele Ugoletti <daniele.ugoletti@puremvc.org>
 Your reuse is governed by the Creative Commons Attribution 3.0 License
*/
package org.puremvc.as3.demos.flex.appskeleton.model.business
{
import mx.rpc.AsyncToken;
import mx.rpc.events.ResultEvent;
import mx.rpc.IResponder;
import mx.rpc.http.HTTPService;

public class LoadXMLDelegate
{
private var responder : IResponder;
private var service : HTTPService;

public function LoadXMLDelegate( responder : IResponder, url:String)
{
// constructor will store a reference to the service we're going to call
this.service = new HTTPService();
this.service.resultFormat = 'xml';
this.service.url = url;

// and store a reference to the proxy that created this delegate
this.responder = responder;
}

public function load() : void
{
// call the service
var token:AsyncToken = service.send();
// notify this responder when the service call completes
token.addResponder( this.responder );
}
}
}

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>
Logged
Pages: [1]
Print