commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Perez Jorge <>
Subject Re: [digester] how to use digester with a class hierarchy
Date Wed, 19 May 2004 09:47:59 GMT

Consider also to add this class to the hierarchy:

class Label extends Component { String text; }

or maybe

class Label extends TextString { /* nothing here */ }

(read on)

Bill Keese wrote:

>I see. In that case, I need to create the Text object when the <text>
>tag is encountered. The question is, how do I save the information that
>appears before the <text> tag?
><x>10</x> <y>20</y>
><text> Hello world </text>
>I suppose that I could have some kind of dummy ComponentBuilder class
>which would sit at the root of the stack and save the x/y value.
>Something like this, maybe:
>digester.addObjectCreate("component", ComponentBuilder.class);
>digester.addSetNext("component/x", "addX"); // save x in ComponentBuilder
>digester.addSetNext("component/y", "addY"); // save y in ComponentBuilder
>digester.setTopRule("component/text", "setXY"); // initialialize Text.x
>and Text.y
>// from values saved in ComponentBuilder
>digester.addSetNext("component/text", "setComponent"); // stores Text
>obj in ComponentBuilder obj
>ComponentBuilder foo = (ComponentBuilder) digester.parse();
>Component realResult = foo.getComponent();

So you are building the concrete component based on the attributes of the
class that seems to be persisted in the xml file. But what would you do if
(at least) two classes, like TextString and Label, have the same attributes?
What specific class will you use to get a new component instance if both
are candidates?

Your big problem is to use the tag <component> for every kind of component,
just to make searches easier. This way DTD's or XML Schema's will not be
for your files, unless you specify all possible child nodes for <component>,
and that will not reflect the hierarchy.

If the use of <component> tag is a requirement I would add a "type" or
"class" attribute to specify the concrete type to use, and you could
develop an
ObjectCreationFactory implementation to create the components. For example:

<component class="TextString">

<component class="Label">
<text>De la pradera</text>


You can still do simple searches. But the nice way for me to do all this is
to use different element names for different components and the search
you use or implement should know about the class hierarchy (or better,
the type).

That search engine should be able to do any of those things:

- to support a union expression like the '|' in xslt patterns so the user
can specify for example something like

"/root/something/(Rectangle | TextString | Label)/x"

to extract the 'x' coordinate of any component. I don't love this too much.

- to understand XML Schema's in the way you can specify an element of
certain XML
Schema type instead of the name or a pattern based on the element name.
a new axis like this will be enought:


This could be cool. Isn't it? Is it already implemented somewhere? Is this
a not so good idea?


Adrian P.J.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message