[jdom-interest] Subclassing Element vs Element Context

[Jehoiada Bernard]

>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
information
you wish without subclassing Element. This seems like a low impact change to
the
current design.

For applications that need to construct some other structure (e.g., a
complex graph)
and navigation/manipulation of that structure doesn't follow a simple
Element traversal
model, subclassing Element doesn't seem to buy very much.

--Jeddy

----- 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
> extensions.
>
> >
> > 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.
>
> --Dave
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com