Thanks for the clarification. So I've mistaken @id for @name.
See below.
----- Original Message -----
From: "Dmitri Plotnikov" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
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:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
