commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james_strac...@yahoo.co.uk>
Subject Re: [Question] Betwix & JAXB
Date Tue, 16 Apr 2002 03:58:10 GMT
----- Original Message -----
From: "Dmitri Plotnikov" <subscriptions@plotnix.com>
> Hi, James, Ivelin,
>
> [...snip...]
>
> > In many cases all these options would be equally good to me.
> > Rarely do I need to customize, although when it's needed it must be
there.
> >
> > >
> > > e.g. for a Map
> > >
> > > Map map = new HashMap();
> > > map.put( "a", "1234" );
> > > map.put( "b", "5678" );
> > >
> > >
> > > how should this look as XML? e.g.
> > >
> > ...
> > > Or
> >
> > Dmitri can probably help here, but I understand that the following form
is
> > becoming popular:
> >
> >
> > Map map = myBean.getItem();
> > map.put( "a", "1234" );
> > map.put( "b", "5678" );
> >
> > <item id="a">1234</item>
> > <item id="b">5678</item>
> >
> > which is consistent with arrays:
> >
> > <item id="1">1234</mapName>
> > <item id="2">5678</mapName >
> >
> >
> > And thus the XPath is natural "/mybean/item[@id='a']"
>
> JXPath takes a dual approach to mapping of maps, or "dynamic property
> objects" as they are called in JXPath.
>
> On the one hand, you can use XPaths like "/map/foo", which are natural
when
> you know that the map is really just a more dynamic sister of a JavaBean,
so
> "foo" is really a property of a logical "bean" called "map".  A good
example
> of such use is a java.util.Properties object.

Though this approach only works when the keys of the Map are Strings, the
value of which are valid XML names (no colon, > <, quotes, spaces etc).


> On the other hand, if your map is used as a generic dictionary and you may
> not even know upfront what keys it will have, the alternative syntax is
more
> preferable:  "/map[@name = 'foo']", or "/map[@name =
> _some_expression_that_computes_the_key_]".  "@name" is an
attribute/keyword
> in JXPath that represents a key or a property name in the case of a
> JavaBean.

Agreed. Or if you've wacky kinda types as keys or values then using XML
elements might be preferable, then additional attributes and sub-elements
can be used to describe the object, such as a type attribute.

e.g.

<map>
    <entry>
        <key type="Double">1234.1234</key>
        <value type="Date">12/02/2002</value>
    </entry>
</map>

> Of course, if you ask what this all means in terms of XML, the answer
would
> probably not be satisfactory. The same thing appears more than once in the
> same "document": once as an element and once as an attribute.   However,
> JXPath does not concern itself with these nuances.  Instead of mapping
every
> kind of object model to the XML document model, it directly defines how
> XPaths are interpreted on those models - no XML involved at all.

XML is a text format - it doesn't really have an implicit object model per
se (though I guess you could argue the InfoSet is an attempt to define an
XML object model but lets ignore that for now). This is one of the reasons
XML is so useful but also why its so confusing.

XPath defines an object model based on documents, elements, attributes and
text nodes (processing instructions & comments are in there too). So we've
really just been talking about the XPath object model but using XML text to
describe what that model looks like. Though I take your point that this
mapping doesn't have to be serializable as XML text. Similarly with DOM
trees they could be recursive too though I'm not sure how useful that is.


> Here's another example of where this distinction manifests itself.  Let's
> say you have a cyclical graph.  You couldn't map it to XML without
> introducing some notion of references and all the related complexity.
With
> JXPath you don't need to do that, because it does not treat JavaBeans as
XML
> structures.  For example, if we have an object like this:
>
>    class Foo {
>       private Foo next;
>       public Foo getNext(){ return next; }
>       public void setNext(Foo foo) {this.next = next;}
>    }
>
>    Foo foo = new Foo();
>    foo.setNext(foo);
>
> We got ourselves a cyclical graph.
>
> In Java, I could say:  foo.getNext().getNext().getNext() and there would
not
> be anything wrong with it.  Likewise, in JXPath,
>
> context = JXPathContext.newContext(foo);
> Foo bar = (Foo)context.getValue("/next/next/next");
>
> Don't even ask me to what the corresponding XML document would look like.
>
> I don't know if this is the "right" approach (the XPath standard, after
all,
> is a child of XML), but it works best for traversing graphs of JavaBeans
and
> does not really hurt the traversal of XML documents.
>
> What do you think?

What would //next do? Do you maintain a set of stuff you've visited to avoid
infinite recursion?

James


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message