[Arp] Central dispatcher

[Christophe Herreman]

Hi guys,

I'm currently not using the central dispatcher and I must admit that it
makes understanding your app easier. What we did wrong before, was to
register Application for event in its subforms! (please don't flame us for
that ;-)) That made it harder to follow the events being sent through the
app. The reason we used it that way, was because we were afraid that the
Application form was going to get bloated with event handlers. It may be
that Application has more code now, but as said, it makes it easier to
understand.

Anyway, working out an implementation of such a central dispatcher was a
good excercise and I'm sure it might come in handy one day.

regards,
Christophe

----- Original Message ----- 
From: "Aral Balkan" <aral at ariaware.com>
To: "Chris Velevitch" <chris.velevitch at gmail.com>; "General List for
Ariaware RIA Platform users and developers" <Arp at ariaware.com>
Sent: Friday, April 22, 2005 10:44 AM
Subject: Re: [Arp] Central dispatcher


> Hi Chris,
>
> I'm sorry if I've misunderstood you. By having a centralized
> EventDispatcher, we would be making every class that has to dispatch
> events reliant on an external class instead of being able to dispatch
> events itself.
>
> Given that we have a Class called "A" and an instance of it called "a".
>
> Encapsulated way:
>
> this.dispatchEvent ( . . . );
> a.addEventListener ( . . . );
>
> Non-encapsulated way:
>
> EventDispatcher.getInstance().dispatchEvent ( . . . );
> EventDispatcher.getInstance().addEventListener ( . . . )
>
>>If you're trying to saying there needs to be a generic class called
>>Event from which application specific events are sub classed then I
>>agree.
>>
> Yes, this would be ideal. And, in fact, I don't like the magic string
> method of using events currently at all. I could much prefer to pass a
> reference to Event class for which we want to listen (eg. SomeEvent)
> instead of its name ("SomeEvent") but lack of reflection means that we
> would have a hard time implementing things like the automatic mapping in
> the ControllerTemplate. I am up to suggestions on this front, though.
>
>>If you mean one part of the application thinks Event X means this and
>>another part of the application thinks Event X means that...well this
>>is a problem of not clearly defining in advance what all the events
>>are and what should they be called. It not a framework issue but a
>>design issue or lack of design.
>>
> Take the V2 framework: The Button component dispatches a "click" event, so
> does the CheckBox class: In the model proposed, would these two events not
> conflict?
>
> All the best,
> Aral
>
> _______________________________________________
> Arp mailing list
> Arp at ariaware.com
> http://ariaware.com/mailman/listinfo/arp_ariaware.com
>