[jdom-interest] Element, Attribute, Document: Factory
kevinr at valicert.com
Sat Jun 3 13:17:33 PDT 2000
I do like this idea. One way of extending it is to
allow the builder itself to be extended. With extended
methods being able to return subclasses of Element, Attribute,
etc. The API could include the name/namepsace prefix/namespace URI,
which could be used to create specialized classes, based
I'm not sure if this falls into the 80/10 theory (probably
more like 95/5 :-) ).
On Sat, 3 Jun 2000, bob wrote:
> I know that it's been discussed before about JDOM
> probably not following the DOM route a using factories
> for Element, Attribute and Document. I think the
> original context of the question was about specializing
> Element into lots of different FooElement, based
> upon the tag name. ie: HREFElement, TableElement.
> What are your thoughts on going 1/2-way that far?
> I'd like to create a single subclass of Elemet, and
> have it used for all Element. Basically, I just want
> to add extra helper methods to the normal Element
> class. Nothing schema/DTD specific. Perhaps I just
> want some slightly different signatures.
> I'd like the FooBuilder to use my single subclass of
> Element(Document/Attribute) instead of the default.
> *Not* specialized by Tag name or anything.
> On a particular builder, I'd like to do this before
> parsing my document.
> builder.setElementClass( MyElement.class );
> builder.setAttributeClass( MyAttribute.class );
> builder.setDocumentClass( MyDocument.class );
> And then parse my document, giving me a tree of my subclasses.
> If those methods aren't used, then normal default org.jdom.*
> classes are used.
> The rationale:
> I'm using WebMacro (www.webmacro.org), and it allows special
> introspect to get to an object, if it's a JavaBean. It does
> special stuff with assuming 'get' prefixes, to produce pretty
> HTML templates.
> translates into
> Purely aesthetical reaons makes me want
> Which would be
> That'd require me adding Element.get() and overriding
> How's that for Too Much Information?
> (yes, someone will argue I should use XSLT or similar,
> but this is legacy project just now adopting XML. No
> hope of migration at this point).
> To control your jdom-interest membership:
More information about the jdom-interest