[jdom-interest] Adding a DocumentListener interface

John Pearcey johnp at mmconsultants.demon.co.uk
Wed Jul 26 01:22:00 PDT 2000


I agree with this - I already proposed a similar thing a few days ago. My
work-around at the moment is to copy the SAXBuilder class to create the
Document object that I need.


-----Original Message-----
From: Chris Atkins <atkicd at nm.usa.alcatel.com>
To: jdom-interest at jdom.org <jdom-interest at jdom.org>
Date: 25 July 2000 23:43
Subject: RE: [jdom-interest] Adding a DocumentListener interface


>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
>
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourho
st.com




More information about the jdom-interest mailing list