I didn't suggest XmlApplication should should store XmlProcessor in a
member variable. I suggested that implementations of XmlApplication
could (if they needed to make callbacks to XmlProcessor) store
XmlProcessor in a member variable.
> >I don't think this is a good idea. It adds complexity and it's likely
> >to impose a performance cost, but it doesn't buy you anything, because
> >you can achieve that functionality with a MultipleXmlApplication class
> >that implements the XmlApplication interface, and provides
> >addApplication and removeApplication methods, and then forwards each
> >event to the applications that have been added to it.
>
> Support of multiple event listeners is the norm in the Java world. As they
> say "When in Texas, wear cowboy boots".
I don't think it's appropriate to carry over patterns from GUI events
and apply them to XML events just because we happen to use the word
"event" to describe them both. I believe performance is important for
XML processing, and an interface shouldn't impose an unnecessary
performance cost.
The real merit of this interface is that it's simple; unless there's a
really compelling need for a feature, I think it should be left out.
> If we were really concerned about performance, I
> would recommend giving up the use of String.
It's (rightly in my view) done that already for character data (which I
think is right). It's not a problem for element type names, because an
implementation can maintain a hash table of names and thus only allocate
a String for each distinct element type.
> >> userData property also gives users a chance to pass extra information
> >> to the processor easily, if they wish.
>
> >Surely there are cleaner ways to do this sort of thing.
>
> I do not think so. Just as every Mac developer loved having RefCon to hang
> thing onto, I like userData.
Could you explain a typical case where you need this?
Are there any standard Java classes that do this?
It feels very wrong to me; it's the sort of thing I would try hard to
avoid in my own programming, but maybe this is my strongly-typed C++
prejudices showing through. To me it seems like a feature that one can
easily manage without.
James