[Arp] Central dispatcher
lists at herrodius.com
Wed Apr 20 02:05:12 PDT 2005
What happens when you have application->childForm->childFormA and
Does application know about these deepest child forms or does childForm form
some kind of buffer to pass (maybe filtered) events to application?
----- 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.
> - 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
More information about the Arp