[jdom-interest] Element Reference from Attribute

[James Strachan]

----- Original Message -----
From: <philip.nelson at omniresources.com>
> > Ok, just to be totally clear, I was talking about MY
> > apllkication where I know what
> > MY XML files are going to look like. This could be handled in
> > a variety of
> > ways, including:
> <snip>
>
> OK, that's the part I didn't understand, that this is for YOUR classes and
> not JDOM.

This technique could be used directly in SAXBuilder (SAXFactory to be
precise) as a configurable optimisation option for caching attribute
instances.

It can be used in any code where people are building their own JDOM tree
(i.e. in their own custom builders). e.g.

public class Foo {
        private static final Attribute blue = new Attribute( "color",
"blue" );
        private static final Attribute defaultFont = new Attribute( "font",
"Verdana" );

    public Element createTitle( String title ) {
        Element element = new Element( title );
        element.add( blue );
        element.add( defaultFont );
        return element;
    }
}

A great use of this idea would be a validating builder that parsed (and
hopefully cached for reuse) a DTD such that all attribute enumerations
specified in a DTD would be shared.

> > *** The point is, if I want to do this, I should be able to.
> > If the API makes it
> > impossible, then I have to go and fork JDOM into SimpleDOM and
> > duplicate alot of work trying to keep the SimpleDOM API  in line with
> > half of the JDOM API. That sucks. :-(
> >
> On that I can agree and from past discussions here, it seems like  there
> would be fairly wide agreement.  The silence on the two level idea
probably
> means something too and probably not what you'd like.

I'm hoping either the silence means there's a lot of thinking going on or
people are just agreeing with me;-)

I hope we don't have to fork JDOM. I've submitted 3 seperate code patches
and addtions so far and have mostly been greeted with silence. Maybe Jakarta
is the way forward.

> Just to clarify, in your scenario, would the xmloutputter and sax/dom
> builders use the simple or the doubly linked classes?

All of the outputters which output to SAX / DOM / XML / HTML et al all use
top down recursion. So they will all work as is with single and doubly
linked tree implementations. No code impact whatsoever.

The same SAXBuilder and SAXHandler will also build both trees, there will
just be 2 implementations of SAXFactory - one for singly linked and one for
doubly linked trees. If you check out the SAXFactory implementation that I
posted to the list...

You'll see implementing this for singly and doubly linked trees is very
trivial. The same pattern can be applied to DOM builders or other custom
building approaches.

The impact on the 2 level tree approach has minimal effect on building and
outputting the JDOM tree. It only really affects what you can do with it
when you've got it and what it costs you.

J.

James Strachan
=============
email: james at metastuff.com
web: http://www.metastuff.com



If you are not the addressee of this confidential e-mail and any
attachments, please delete it and inform the sender; unauthorised
redistribution or publication is prohibited. Views expressed are those of
the author and do not necessarily represent those of Citria Limited.