[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RFC: Simple XML Event-Based API for Java

• From: James Clark <jjc@j...>
• To: xml-dev Mailing List <xml-dev@i...>
• Date: Wed, 17 Dec 1997 17:47:27 +0700

Don Park wrote:
 
> >I don't see the point of the XmlProcessor first argument.  What's wrong
> >with having the implementation of XmlApplication store the XmlProcessor
> >in the member variable?  (This is what SP typically does.)
> 
> XmlApplication can not store the XmlProcessor in the member variable because
> it is an interface.  I am very happy to see that XmlProcessor and
> XmlApplication are interfaces rather than classes. 

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


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: RFC: Simple XML Event-Based API for Java
    • From: Peter Murray-Rust <peter@u...>

• References:
  • Re: RFC: Simple XML Event-Based API for Java
    • From: "Don Park" <donpark@q...>

• Prev by Date: Re: RFC: Simple XML Event-Based API for Java
• Next by Date: Re: inclusions/exclusions/named groups
• Previous by thread: Re: RFC: Simple XML Event-Based API for Java
• Next by thread: Re: RFC: Simple XML Event-Based API for Java
• Index(es):
  • Date
  • Thread