[jdom-interest] Adding a DocumentListener interface

[Chris Atkins]

Would it make sense to make specifying the specific class of JDOM items,
Element, Document, ....,  part of the api?  I have seen this question
come up in various forms multiple times.  It does not make a lot of
sense to have folks copy the SAXBuilder and/or DOMBuilder classes
to change the classes which are being created.

I would suggest that SAXBuilder and DOMBuilder have a pointer to a
JDOMItemFactory(Have an interface for this and a default implementation).
Whenever a jdom item needs to be created, the Builder asks the factory.  The
JDOMItemFactory has package methods for creating the various jdom items,
Document, Element, Entity, Namespace, PI.  The SAXBuilder and DOMBuilder
both get a new method to allow one to swap out the JDOMItemFactory,
setItemFactory(JDOMItemFactory factory).

Adding this capability to the api, one can just subclass JDOMItemFactory
to create the correct type of items.

With the problem of being able to specify the specific class for Element,
.... out of the way, then decide on whether to have subclasses of the
various jdom items which allow registering and deregistrering for change
listeners and where they should go, jdom or jdom.XXXXXXX

If adding the ability to set the item factory, you might give some thought
to creating interfaces for the various jdom items so one would not
necessarily have to subclass from jdom.Element for example, but implement
jdom.ElementIF.


Chris Atkins

> -----Original Message-----
> From: jdom-interest-admin at jdom.org
> [mailto:jdom-interest-admin at jdom.org]On Behalf Of Jason Hunter
> Sent: Tuesday, July 25, 2000 3:26 AM
> To: yt at sideshowbobproject.com
> Cc: jdom-interest at jdom.org
> Subject: Re: [jdom-interest] Adding a DocumentListener interface
>
>
> yt at sideshowbobproject.com wrote:
> >
> > I am also working on this project with Ken. We were
> thinking about writing a set of
> > wrapper subclasses for the document/elements, but we were
> unsure of how to go about
> > coercing the parser to create Element wrapper subclasses
> (in lieu of normal
> > Elements) without changing the JDOM code. Is there
> something that we're not seeing?
>
> An easy hack is to have a converter that converts from a normal JDOM
> document to a special JDOM document (just like JDOM can
> convert from DOM
> to JDOM, only easier to write).  A higher performance hack is
> to change
> SAXBuilder to create your kind of elements.  A high
> performance elegant
> solution is to change SAXBuilder to be pluggable for the kinds of
> elements it creates, using something like an internal
> factory.  Off the
> cuff I'd say you want an Element createElement(...) protected method
> that a subclass of SAXBuilder can override to create subclasses of
> Element, and so on for the other JDOM objects.
>
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr at yourhost.com


> -----Original Message-----
> From: jdom-interest-admin at jdom.org
> [mailto:jdom-interest-admin at jdom.org]On Behalf Of Jason Hunter
> Sent: Tuesday, July 25, 2000 3:26 AM
> To: yt at sideshowbobproject.com
> Cc: jdom-interest at jdom.org
> Subject: Re: [jdom-interest] Adding a DocumentListener interface
>
>
> yt at sideshowbobproject.com wrote:
> >
> > I am also working on this project with Ken. We were
> thinking about writing a set of
> > wrapper subclasses for the document/elements, but we were
> unsure of how to go about
> > coercing the parser to create Element wrapper subclasses
> (in lieu of normal
> > Elements) without changing the JDOM code. Is there
> something that we're not seeing?
>
> An easy hack is to have a converter that converts from a normal JDOM
> document to a special JDOM document (just like JDOM can
> convert from DOM
> to JDOM, only easier to write).  A higher performance hack is
> to change
> SAXBuilder to create your kind of elements.  A high
> performance elegant
> solution is to change SAXBuilder to be pluggable for the kinds of
> elements it creates, using something like an internal
> factory.  Off the
> cuff I'd say you want an Element createElement(...) protected method
> that a subclass of SAXBuilder can override to create subclasses of
> Element, and so on for the other JDOM objects.
>
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr at yourhost.com