This works really nicely if all you need to do is to read data into Java
beans. It's kinda like Apache Digester meets annotation.
But this is much harder to do for read/write systems like JAXB, partly
because XPath is not reversible. Consider:
class Foo {
@XPath("count(item[@number='x'])")
int x;
@XPath(".//_at_id")
String id;
}
And it gets even harder if we need to generate a schema for it.
If all we want is to collapse deep element wrappers into one class, then
giving it "XPath" as the name would send wrong impression to people, I
think.
Kenny MacLeod wrote:
> Folks,
>
> I have an idea for a possible enhancement to JAXB which I'd like to
> throw open to the floor. It would involve a new annotation type which
> takes an XPath expression, and uses that expression to bind to the field
> /property being annotated.
>
> This could come in handy when binding to XML documents which are not
> conveniently structured, perhaps those with too many levels of
> structure, allowing you to flatten out the structure in your class model.
>
> For example, take the following XML fragment:
>
> <book>
> <title>The Dice Man</title>
> <catalog>
> <isbn>0006513905</isbn>
> </catalog>
> </book>
>
> Let's say that I don't want the <catalog> intermediary type, but to
> flatten tht <title> and <isbn> together into the same type.
>
> With the new annotation, I could do something like this:
>
> public class Book {
>
> @XmlElement
> String title;
>
> @XPath(path="catalog/isbn")
> String isbn;
> }
>
> When the JAXB runtime finds the @XPath annotation, it would evaluate it
> against the "current" node, i.e. the <book>, and assign the result to
> the field.
>
> This concept could be taken much further - you could have an annotated
> class which cherry-picks pieces of data from deep inside the node
> structure and flattens them out. The ability to mix and match this
> approach with other JAXB binding constrructs would be quite powerful, I
> think.
>
> Any thoughts?
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com