[Arp] Central dispatcher

[Christophe Herreman]

Hi Nils,

What happens when you have application->childForm->childFormA and 
application->childForm->childFormB?
Does application know about these deepest child forms or does childForm form 
some kind of buffer to pass (maybe filtered) events to application?

regards,
Christophe

----- Original Message ----- 
From: "Nils Millahn" <nils.millahn at deltabravo.com>
To: "Johan Lopes" <johan.lopes at gmail.com>; "General List for Ariaware RIA 
Platform users and developers" <Arp at ariaware.com>
Sent: Wednesday, April 20, 2005 10:51 AM
Subject: Re: [Arp] Central dispatcher


> Hi All,
>
> (just realised I kept calling it event dispatcher rather than central 
> dispatcher ;) just ignore please ;))
>
> I've been thinking about this for a while and have used similar techniques 
> in my own projects but I don't think it's the right approach - it makes 
> life easier but doesn't reduce dependencies amongst the forms/views.
>
> First off - if you want to use a central dispatcher, I think there is 
> already a perfect place for it - the main Application form, which contains 
> all views. That could inherit from EventDispatcher or perhaps implement an 
> EventDispatcher interface, to relay events from and to its child forms.
>
> The reason I don't think it reduces dependencies is that you will still 
> write code in a child form that specifically reacts to an event broadcast 
> by another. Eg - Form A broadcasts event, Form B receives that event (via 
> EventDispatcher) and handles it - so there is a method in Form B that 
> interacts with Form A on a very basic level.
>
> The question for me is always - if you removed Form A from the 
> application, would there be code left in Form B that was made redundant - 
> and the answer is clearly 'yes'. Similarly, if you didn't have access to a 
> child form's class code, could you still make it react to the event - and 
> the answer would be 'no'.
>
> But I think that the ARP structure already addresses these issues - the 
> main Application form is the right place to handle these events. It is the 
> only place that should have specific knowledge about the other forms - 
> after all, they are its children. You give each child Form the 
> functionality it requires - but don't give it the means to react to other 
> child forms' events. The main Application form however does listen to 
> events from its child forms and then calls specific methods in each child 
> to react to that event.
>
> Benefits:
> - all code that reacts to a specific event is contained in a single 
> method - if you don't want to react to that event anymore, you don't need 
> to edit each child form's class
> - the child forms remain self-contained - no code dependencies (you 
> develop functionality to do what you need it to but don't include the code 
> to react to the events)
>
> etc :)
>
> - Nils.
>
>
> _______________________________________________
> Arp mailing list
> Arp at ariaware.com
> http://ariaware.com/mailman/listinfo/arp_ariaware.com
>