commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Keese <>
Subject Re: [digester] how to use digester with a class hierarchy
Date Thu, 20 May 2004 01:03:30 GMT
 Adrian Perez Jorge points out that I need to be able to persist the
following objects in a non-ambiguous way:

> <>class Text extends Component { String text; }
> class Label extends Component { String text; }

I see your point. Maybe when I persist a class from a class hierarchy, I
should make an element for the concrete class, and an element for each

class A { int x; }
class B extends A { int y; }
class C extends B { int z; }

XML to represent an instance of class C:

Search string for all A objects where x=1:

This representation is not ambiguous, even when classes have the same
member names (or no member names). The <object> tag has no function
other than to bundle up the <a>, <b> and <c> tags. So maybe rather than
<object> I should use <c> as the outer tag, or <object type="c"> as you

> 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">
> <x>10</x>
> <y>20</y>
> <text>Pecador</text>
> </component>

Cool, I didn't realize that you could create different objects depending on the attributes
on the root tag.  That's pretty convenient.

> "/root/something/(Rectangle | TextString | Label)/x"
> to extract the 'x' coordinate of any component. I don't love this too
> much.

Yeah, you would have to change your search string every time you added a
new class.

> Maybe a new axis like this will be enought:
> "/root/something/xsdtype::component/x
> This could be cool. Isn't it? Is it already implemented somewhere? Is this
> a not so good idea?

Hmm, interesting. Similar to a wildcard I guess.

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

View raw message