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
superclass.
JAVA:
class A { int x; }
class B extends A { int y; }
class C extends B { int z; }
XML to represent an instance of class C:
<object>
<a><x>1</x></a>
<b><y>2</y></b>
<c><z>3</z></c>
</object>
Search string for all A objects where x=1:
/*[a/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
suggested.
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
