[Arp] Central dispatcher

[Chris Velevitch]

On 4/20/05, Nils Millahn <nils.millahn at deltabravo.com> wrote:
> 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.

I disagree. Just because both forms know about an events of type X
does not imply the forms explicitly knows about each other.

> 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'.

Not necessarily. If Form A is the only object that generates type X
events, then yes, Form B has redundant code. But if type X events can
be generated from other objects, then that code not redundant.

> 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.

I don't think it's necessary for the main Application Form to know
about every possible event.

>                                     You give each child Form the
> functionality it requires - but don't give it the means to react to
> other child forms' events.

I think you've got this the wrong way around. A form has been designed
to listen for a particular set of events and it has been designed to
generated a particular set of events. A form should not care where the
event comes from or where it goes to. It's sole reason for being to
respond to events. And if the response to an event is to generate an
event then so be it.

>                            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.

Again, necessarily. So far you've talk only about inter form
communication. What if the event relates to business logic? Why must
the main Application form be involved if a child form sends an event
to a command?