[jdom-interest] Parents - why do we need them?

[philip.nelson at omniresources.com]

> >That's the whole idea of "Shared"; my target was definitely 
> not memory
> >optimization, but the ability to change the attributes of 
> many elements with
> >a single call. Another approach could be to use an Attribute 
> that uses a
> >StringBuffer for the value, and exposes it - so I can use the same
> >StringBuffer for many Attributes, and change it later.
> 
> That might be the most graceful of the possibilities, since it would
> provide a fairly trivial way to implement copy-on-write as well, for
> those who want that.  Feel like implementing an example?

I pretty much agree with Amy on the prior stuff.  This idea is good but try
to be very careful about performance.  Alex Rosen had put together a pretty
compelling argument as to why StringBuffer was a bad choice for the Text
class that may be worth reviewing.

A subclass could accomplish this pretty easily I would think and then my
point would be pretty much moot at least as it affects the rest of the api.

Here is another idea, definately not thought through but I throw it up for
discussion.  One of the great unresolved parts of the api is the null and
bad type addtion problem with the lists.  We are assuming that the best idea
is to filter these out on the insertion.  Yet this idea of a shared
attribute, points to another idea.  What if the default behaviour of the
outputters was to ignore anything that wasn't a core JDOM class/subclass.
Nulls? disregard.  JTextBox? disregard.  Take the unhandled branch of the
outputter iteration one step further though and allow for a custom renderer
to be plugged in and a whole new range of patterns becomes possible.

possibilities ???
Add a List of xml content to the content list of one document from another
render a JDBC resultset directly into a template output document
Shared attribute implemented as a new class and renderer
throw a TableModel in and add it to a document

It would take some pretty careful looking at the api to see if this is even
possible because, while much of the burden of well-formed-ness and namespace
compliance and the like would be on the developer of the custom renderer, it
may not be easy to find ways to call the custom renderer at the correct time
to place things in all arbitrary locations of the document.  

Just a thought.