commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: [Question] Betwix & JAXB
Date Fri, 12 Apr 2002 05:38:39 GMT

Thanks for the clarification. So I've mistaken @id for @name.

See below.

----- Original Message -----
From: "Dmitri Plotnikov" <subscriptions@plotnix.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Thursday, April 11, 2002 10:49 PM
Subject: Re: [Question] Betwix & JAXB


> 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.
>
> 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.
>
> 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.
>
> 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 would love it if the new Betwix marshaling with href and id's generates an
XML file,
which would be equally valid to apply against "/next/next/next/".
Not quite familiar how XPath would treat XLink refs.

>
> 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?
>
> [...snip...]
>
> >
> > Ivelin
> > >
> > > James
>
> Regards,
>
> - Dmitri
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


--
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