[jdom-interest] Factories for builders.

[Richard Cook]

Certainly was easy, contrived eg to only choose elements starting with "xsl"
and create an Element subclass:

builder = new SAXBuilder(saxDriverClass, true,
           new DefaultSAXHandler() {
             public Element createElement(String n, Namespace ns) {
                System.out.println("create elemnt " + n);
                return new MyElement(n,ns);
             }

             public void startElement(String namespaceURI, String localName,
                                      String qName, Attributes atts)
                                      throws SAXException {
                if (qName.startsWith("xsl"))
super.startElement(namespaceURI,localName,qName,atts);
             }
             public void endElement(String namespaceURI, String localName,
String rawName) {
                if (rawName.startsWith("xsl"))
super.endElement(namespaceURI,localName,rawName); }

           });

seemed to work on samples/namespaces.xml and for only a few lines changed.

you do kind of have to know to call endElement for each startElement, and
SAXHandler does get to be public; but for what I want(ed) I either call
super() or ignore so I'm not really depending on implementation; I suspect I
would have had a harder job trying to work on fragments and then chuck them
away and i'm sure theres lots of reasons not to do this.

what i'd really like is for this kind of thing to be possible and for
library developers to have some means [javadoc tag?] by which they could
tell people "you can do this but be aware of these gotchas"





> -----Original Message-----
> From: jdom-interest-admin at jdom.org
> [mailto:jdom-interest-admin at jdom.org]On Behalf Of GB/DEV - Philip Nelson
> Sent: Sunday, March 11, 2001 2:49 PM
> To: jdom-interest at jdom.org
> Subject: RE: [jdom-interest] Factories for builders.
>
>
> > This is kind of why when I wanted similar functionality I
> > added SAXHandler
> > param. to SAXBuilder constructors, and template
> > createElement()/Attribute()
> > methods to SAXHandler.
>
> The absolutely simplest thing I can can think of is to just provide and
> alternative SAXHandler subclass name in the SAXBuilder constructor.  If
> SAXBuilder sees it, it instantiates it cast as a SAXHandler.  For
> every need
> to use custom elements I have thought of, this would suffice.
> Override one
> or two methods and viola, custom JDOM elements.  When this
> doesn't suffice,
> you can subclass SAXBuilder now and do whatever you want.
>
> The only obvious problem I can think of (OK it's probably not the only
> problem) is that because SAXHandler is package protected, you
> would have to
> create your subclass in the org.jdom.input package.  I know there were
> reasons for that, probably thinking that SAXHandler is an implementation
> detail, but it seems to me that this approach is very easy to implement.
> For JDOM it's another constructor and a few lines of code.  In most cases,
> for a developer where you just want to customize a few pieces of JDOM
> elements, attributes etc., its very easy.  If a developer wants
> to do a more
> drastic overhaul, no problem, you can override all of SAXHandler, or build
> with your own builder.  The last one is tougher though because you need to
> know a *lot* about xml and jdom to make it work.
>
> So, what have I missed ;^)
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yourad
dr at yourhost.com