Lists Home |
Date Index |
- From: "Don Park" <firstname.lastname@example.org>
- To: "xml-dev Mailing List" <email@example.com>
- Date: Wed, 17 Dec 1997 14:18:50 -0800
>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.
OOPS. Point taken.
>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
>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.
While David suggested that add/removeApplication methods allow
implementation of XmlProcessors which support multiple XmlApplications, it
is completely up to the implementations to support multiple XmlApplication
or only one at a time. As JavaBeans spec suggests,
TooManyListenersException should be thrown if XmlProcessor supports only one
XmlApplication for performance and simplicity sake.
>> I do not think so. Just as every Mac developer loved having RefCon to
>> thing onto, I like userData.
>Could you explain a typical case where you need this?
>Are there any standard Java classes that do this?
userData is a cheap way to associate extra info with the XmlProcessor. For
example, I can store the source URL in the userData. There are other ways
to have XmlProcessors provide the URL info (i.e. Java Activation Frame has
URLDataSource for this) but they are fairly expensive and would
unnecessarily taint the API with URL related stuff. It should be possible
to use XmlProcessor with a File and building URL out of File is not reliable
in all platforms.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)