[jdom-interest] Subclassing Element vs Element Context
jbernard at rochester.rr.com
Sat Nov 4 13:38:00 PST 2000
>Simple case: after parsing a document, I want to process all elements,
>and mark them with a flag "visited" to I know I processed them. I
>*could* do this by creating another set of data structures that *point*
>to the element, but it would be easier, less memory intensive, and
>downright convenient if I could simply create a subclass of Element that
>has the extra flag.
For applications that navigate the document as a simple tree of Elements,
how about simply being able to attach contextual information to an element?
e.g., element.setContext(Object); You could then color the tree with any
you wish without subclassing Element. This seems like a low impact change to
For applications that need to construct some other structure (e.g., a
and navigation/manipulation of that structure doesn't follow a simple
model, subclassing Element doesn't seem to buy very much.
----- Original Message -----
From: "Dave Churchville" <dmc at clearlight.com>
To: <jdom-interest at jdom.org>
Sent: Saturday, November 04, 2000 12:58 PM
Subject: Re: [jdom-interest] what is JDOM?
> > In my view, JDOM should be designed to faithfully represent the XML
> > document (both as an end in itself, and as an intermediate
> > representation between XML documents and Java data), but JDOM should not
> > go out of its way to support arbitrary data binding itself.
> Agreed, data-binding is about converting "generic" XML data into
> specific, typed Java classes. JDOM is clearly about loading generic XML
> data into a generic Java representation (Element, etc.)
> > To fully support data binding, I believe, JDOM would need a complete set
> > of interfaces for alternate implementations, carefully crafted template
> > classes for custom extensions, and factories.
> Well, it would be something other than JDOM, I think, not a set of
> > When people ask about how to override methods in Element or how to
> > create their own SAXBuilder, I wonder if they're working with the wrong
> > tool.
> At least for my needs, the ability to override methods, use custom (or
> enhanced) SAXBuilders, etc., is to enhance the *generic* data model
> capabilities for an app-specific purpose. For example, when writing a
> tool or utility that will process XML in some way, there is often a need
> for "housekeeping" or "tag-along" data that you wish to hang on the
> generic element.
> Simple case: after parsing a document, I want to process all elements,
> and mark them with a flag "visited" to I know I processed them. I
> *could* do this by creating another set of data structures that *point*
> to the element, but it would be easier, less memory intensive, and
> downright convenient if I could simply create a subclass of Element that
> has the extra flag.
> My application could then use "standard" JDOM things to save or modify
> the generic data model, since I only needed the extra information for
> in-memory processing.
> To control your jdom-interest membership:
More information about the jdom-interest