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