Hi Ace,
I think your complaint is having to create a callback for every
event/command invoked by your view and it is possible to avoid that.
If thats not what you meant I apologize and disregard the rest of this
message. :)
Our general approach is to pass ResultEvents back from delegates to
commands and where necessary back to the view as well. (Via
notifyCaller(), the aspect of UM Cairngorm of interest here.) Inside
our delegates we sometimes use AsyncTokens so that we can have a
single result/fault handler for all of the delegate's remote calls.
Since ResultEvent has a token property you can actually pass those
back to the commands and views as well to allow a single handler
containing a switch statement or whatever. For example:
In your view:
dispatchEvent(new CoolStuffEvent(new Callback(defaultCallback)));
dispatchEvent(new DumbStuffEvent(new Callback(defaultCallback)));
In your delegate method:
var token:AsyncToken = myService.send()
token.callID = CoolStuffEvent.EVENT_ID / DumbStuffEvent.EVENT_ID;
Your delegate's handler:
private function handleResults( event:ResultEvent ):void
{
switch( event.token.callID )
{
case CoolStuffEvent.EVENT_ID:
notifyCaller( new ResultEvent( ResultEvent.RESULT,
false, true, new
VOFactory( XML( event.result ) ).someVO, event.token ) );
break;
case DumbStuffEvent.EVENT_ID:
notifyCaller( new ResultEvent( ResultEvent.RESULT,
false, true,
event.result, event.token ) );
break;
}
}
That handler is passing the ResultEvents to the command, which will in
turn pass them to the view. So back in
defaultCallback(event:ResultEvent) in your view you can switch on
event.token.callID just like we did in the delegate or inspect the
token in some other helpful way.
Whew, I really hope thats what you were asking about :)
HTH,
Ben
--- In flexcoders@yahoogroups.com, "ACE" <[EMAIL PROTECTED]> wrote:
>
> I like the fact that someone found this to be a problem and cared to
> make this as a framework. When, I needed this, I was writing my custom
> code.
>
>
> But, I do not like the implementation for the simple reason, that if a
> View say View-1 needs synchronous information from 2 commands, it
> cannot, because both the commands will be sending the data to the view
> which would be the callback. Hence, to handle such scenario, you will
> have to write as many callbacks which talk to the view. Fails to scale
> gracefully.
>
>
> This is where the "Interface" based programming fails and why event
> based programming is so powerful. What you need is an ServiceBus that
> can carry the event with some contextual information and and then pass
> back intelligently.
>
> I do not have an opinion on modules, yet.
>
