[jdom-interest] Code submision: JDOM2 the dual tree implement ation...

[James Strachan]

----- Original Message -----
From: "Patrick Dowler" <Patrick.Dowler at nrc.ca>
> On Thu, 23 Nov 2000, you wrote:
> > I'm about to post a full implementation of the 2 tree JDOM for your
review.
> > I've noticed that patch submissions often take a while to get though to
the
> > list, so I thought I'd introduce it first ;-) The full source code will
be a
> > few hours later...

It requires moderator approval, so it will be here any day now ;-)

> Since I also argued for this split,
>
> > The effect on the API is suprisingly minimal.
>
> Since the doubly-linked subclasses are strictly adding features, this
isn't
> surprising, In fact, that is what made the whole idea appealing in the
first
> place :-)

:-)

> ProcessingInstruction?

Hangs off Document right now so doesn't come under the singly / doubly
linked tree discussion. We might want a mutable and immutable implementation
though. PIs aren't very common though whereas Attributes and Entites are so
for this version I didn't concern myself much with them.

> > There were little typesafe methods on Element for Comment/Entity/CDATA.
> > Though I've added a couple of typesafe helper methods for Attribute on
> > Element...
>
> Not sure if helper methods are what you really want here. First, user code
could
> do this quite easily.  In general, such helper methods add to the API
without
> really allowing you to do something you couldn't do. if enough people are
> wriitng the same code, then it makes sense, but I'd hold off on this for a
bit.

I'm inclined to agree. Though there are quite alot of other helper methods
around the core implementations of Element / Attribute that I thought it be
prudent to follow suit. I've only done this for Attribute / AttributeNode;
there are no typesafe methods for dealing with an elements content (Element
/ Comment / CDATA / Entity ...).

> Also, I don't know that immutable vs. mutable and singly vs. doubly linked
are
> "necessarily" related.

My thinking was along the lines of killing 2 birds with 1 stone.

Singly should promote sharing. Making the default singly linked attribute
immutable make sharing easy as there is need to worry about someone changing
its value.

Doubly cannot allow sharing so there is no benefit from it being immutable.
Might as well be mutable so "power users" can mutate trees in place.

> Some people might have good reason for mutable/shared
> attributes, for example*. They could do it by implementing the Factory
appropriately.
>
> * I could write a pretty fast "in-place" transformer if I was interested
in changing
> ALL instances (that is, all shared instances) of something into something
else :-)

Sure. The door is open to allow people to derive from the immutable
Attribute to implement a new mutable attribute which can also be shared.
This may be useful in some special cases. I think the proposed API of
Attribute and AttributeNode supports all of these cases sufficiently.

> > None of the outputters or adapters are affected by any of these changes.
The
> > only other change is in the input package. I've renamed my previously
> > submitted "SAXFactory" to be "JDOMFactory". This class is now reused
with
> > minimal change in DOMBuilder and SAXBuilder / SAXHandler.
> >
> > There is a new JDOMFactory implementation, which I've called
JDOM2Factory
> > for now (horrible name) which is used to build the full doubly linked
tree.
>
> One downside to all this is that it is a nice feature of JDOM to use "new"
instead
> of a factory in your code. Of course, once people start subclassing, they
can
> chose "new" vs. "factory" as they see fit, so it is just the people who
use the
> API as is that have to take care. It would be very nice to not force
everyone to use
> the factory pattern in their own code and yet me maintainable...

Agreed. Though developers can choose between String (immutable) and
StringBuffer (mutable) without many problems, I'm assuming they can make the
same call with Attribute / AttributeNode. I've often found it useful to use
the 'factory method' design pattern when creating objects anyway. This
practice may become quite common when building JDOM trees.

> Once upon a time I tried this sort of thing by naming the base and
subclasses
> the same and only changing the package name. Then you could "upgrade" to
> the power-feature set simply by changing the import statement, and all
your
> uses of "new" were OK.
[snip]
> Are there any catches to this strategy?
>
> Other than the millions of "this won't compile" messages on the mailing
list :-)
>
> Is it madness?

Its not madness, its just one way of doing it.
I can imagine people wanting to mix and match a bit though so I'd prefer
different class names in the same package.
For example:-

    public void setFooValue( Element element, String value ) {
        Attribute attribute = element.getAttribute( "foo" );
        if ( attribute instanceof AttributeNode ) {
            AttributeNode node = (AttributeNode) attribute;
            node.setValue( value );
        }
        else {
            if ( attribute != null ) {
                element.removeAttribute( attribute );
            }
            element.addAttribute( new Attribute( attribute, value ) );
        }
    }

though admitedly the above code could be hidden inside some helper methods
in Element.


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.