Skip to main content

[RT] Mapping Objects to XML Files using Java 5 Annotations

5 replies [Last post]
Anonymous

While refactoring stuff in reorg, I noticed how it can be difficult to
keep in synch jndc and the xml version, as they are now in two packages.

I thought that it would be nice to have Java5 annotations in the jndc
classes that can be used by a processor to make the xml-reading stuff.

ANd here is a very nice article about it:

Mapping Objects to XML Files using Java 5 Annotations:

http://www.javaspecialists.co.za/archive/Issue097.html

--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Patrick Wright

Nicola

Just a couple of thoughts

> While refactoring stuff in reorg, I noticed how it can be difficult to
> keep in synch jndc and the xml version, as they are now in two packages.
>
> I thought that it would be nice to have Java5 annotations in the jndc
> classes that can be used by a processor to make the xml-reading stuff.
>
> ANd here is a very nice article about it:
>
> Mapping Objects to XML Files using Java 5 Annotations:
>
> http://www.javaspecialists.co.za/archive/Issue097.html

When I read your email, and before reading the article, I thought "ack!
isn't that inflexible?"

The code in the article looks pretty clean to me. The downside might be
that it would be non-obvious to add a different mapping to load from XML,
for example, if someone wanted to write a XUL or {pick your XML GUI
storage format} which in theory would be nice to support. There is no
reason one could not have both--let JDNC use annotations for the standard
XML format, but allow people to load from other formats using a custom
mapping.

When mappings are out of sync it is, in my experience, a hassle to debug.

The example in the code first builds a Document and then parses from the
root downward. How hard would it be to rewrite that in SAX? I think there
are XPath/SAX filters floating around--you could reverse the sequence of
operations and start with the Component, get the fields with annotations,
and pass the list of XPaths into the SAX Content Handler (or
XMLReaderImpl, as a filter), then match on the XPath as you go, ignoring
other elements. That way you avoid the memory cost of a Document you
otherwise don't need.

I think this is a nice idea to explore. Other opinions?

Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Nicola Ken Barozzi

Patrick Wright wrote:
...
> The downside might be
> that it would be non-obvious to add a different mapping to load from XML,
> for example, if someone wanted to write a XUL or {pick your XML GUI
> storage format} which in theory would be nice to support. There is no
> reason one could not have both--let JDNC use annotations for the standard
> XML format, but allow people to load from other formats using a custom
> mapping.

Or write an xslt stylesheet or SAX Filter that transforms one format in
the other.

> When mappings are out of sync it is, in my experience, a hassle to debug.

IMHO mapping in code could make it easier to keep things in synch.

> The example in the code first builds a Document and then parses from the
> root downward. How hard would it be to rewrite that in SAX? I think there
> are XPath/SAX filters floating around--you could reverse the sequence of
> operations and start with the Component, get the fields with annotations,
> and pass the list of XPaths into the SAX Content Handler (or
> XMLReaderImpl, as a filter), then match on the XPath as you go, ignoring
> other elements. That way you avoid the memory cost of a Document you
> otherwise don't need.

IMHO this is not something so important, as it should be loaded only
once at startup. Besides, it's so convenient working with xpaths, and I
would prefer not do the parsing ot them myself ;-)

Jakarta Commons Digester (http://jakarta.apache.org/commons/digester/)
works with Sax, but the metadata is still in code or in xml, not what I
would call a step forward.

> I think this is a nice idea to explore. Other opinions?

--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Patrick Wright

Nicola

> Or write an xslt stylesheet or SAX Filter that transforms one format in
> the other.

Good point. Maybe the current code could be offered as an example of how
it could be done without using attributes (for those who need another
storage format).

>> When mappings are out of sync it is, in my experience, a hassle to
>> debug.
>
> IMHO mapping in code could make it easier to keep things in synch.

Why? Just to be devil's advocate for a moment:
1) When a class is large, fields tend to get swallowed in the mass of
comments, methods, constants and such. Checking whether all of them are
mapped, and how they are mapped, would still be a step-by step process.

2) One would need to write a separate test utility to extract XPaths and
see if they correspond to anything real, as the compiler won't check. A
casual "/" or other symbol typed accidentally will be overlooked until
that attribute fails to load (and it could be something subtle). Whereas
a mapping file can be tested using a combination of normal schema tools
(I think).

3) Seems like attributes in code don't allow for easy versioning of the
XML--e.g. we need to be able to upgrade and change the XML format over
time. With mapping, you can have a V1 map, a V1.1 map, a V2 map, and the
same persisted XML can be loaded just by looking at a version number.
With attributes, you have...what?

> IMHO this is not something so important, as it should be loaded only
> once at startup. Besides, it's so convenient working with xpaths, and I
> would prefer not do the parsing ot them myself ;-)

I don't want to do the parsing either. I think it depends on the type of
application JDNC is targeting. A nice thing about XML storage of form
component/layout/binding is that it can be much faster to load than a set
of classes. Don't want to reduce that convenience with an unnecessary
Document--memory and time being the issues.

> Jakarta Commons Digester (http://jakarta.apache.org/commons/digester/)
> works with Sax, but the metadata is still in code or in xml, not what I
> would call a step forward.

I think that's the one I was thinking of...

Not against the idea, but want to try and knock it down, see if it holds
up under scrutiny.

Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Nicola Ken Barozzi

Patrick Wright wrote:
> Nicola
...
>>>When mappings are out of sync it is, in my experience, a hassle to
>>>debug.
>>
>>IMHO mapping in code could make it easier to keep things in synch.
>
> Why? Just to be devil's advocate for a moment:
> 1) When a class is large, fields tend to get swallowed in the mass of
> comments, methods, constants and such. Checking whether all of them are
> mapped, and how they are mapped, would still be a step-by step process.

This would not change with an external class... it would be even worse,
as after finding the field I have to write the mapping logic in another
place!

> 2) One would need to write a separate test utility to extract XPaths and
> see if they correspond to anything real, as the compiler won't check. A
> casual "/" or other symbol typed accidentally will be overlooked until
> that attribute fails to load (and it could be something subtle). Whereas
> a mapping file can be tested using a combination of normal schema tools
> (I think).

Then the schema has to be correct... so to add or change stuff one needs
to :

1- add the field in the jdnc package
2- write the mapping logic in another file in the markup package
2a - give up ;-)
3- update the schema
4- check that all works well

> 3) Seems like attributes in code don't allow for easy versioning of the
> XML--e.g. we need to be able to upgrade and change the XML format over
> time. With mapping, you can have a V1 map, a V1.1 map, a V2 map, and the
> same persisted XML can be loaded just by looking at a version number.
> With attributes, you have...what?

Well, ATM we have a set of classes in the markup packages that do the
mapping. If they were in the jdnc code instead, it would be easier to
maintain. A schema can still be kept, just as now.

>>IMHO this is not something so important, as it should be loaded only
>>once at startup. Besides, it's so convenient working with xpaths, and I
>>would prefer not do the parsing ot them myself ;-)
>
> I don't want to do the parsing either. I think it depends on the type of
> application JDNC is targeting. A nice thing about XML storage of form
> component/layout/binding is that it can be much faster to load than a set
> of classes. Don't want to reduce that convenience with an unnecessary
> Document--memory and time being the issues.

For memory, I doubt that we will have multi-megabyte files to parse.
IMHO the speedup of the use of SAX instead of DOM in this case is
neglible... in any case it has to be tried with real code before really
knowing it ;-)


IMO classes can be much faster than XML to load.
Try taking a moderately Serializable complex object tree and serialize
it, and them serialize it in XML... I usually find that the XML version
is much much slower in coming up.

>>Jakarta Commons Digester (http://jakarta.apache.org/commons/digester/)
>>works with Sax, but the metadata is still in code or in xml, not what I
>>would call a step forward.
>
> I think that's the one I was thinking of...

I guess I gotta try and lay down some code to try it.

OTOMH... maybe we can use XSLT to transform the XML to the XML used by
bean serialization and load them from that. Gotta check.

> Not against the idea, but want to try and knock it down, see if it holds
> up under scrutiny.

That's what I need :-)

--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Patrick Wright

Nicola

Fun!

> This would not change with an external class... it would be even worse,
> as after finding the field I have to write the mapping logic in another
> place!

I agree, but...one problem I have with annotations (which, oddly, I was
calling attributes just a minute ago) is that they *can* add metadata that
is orthogonal to the general purpose of the class right in the middle of
the code. The syntax is right in your face. So there's a bunch of fields,
methods, comments, javadoc, etc. and now annotations on top of that that
you have to work your way through. An advantage of external mapping is
that you just keep it out of the way--it's really only interesting for
that 1 week a year that you are updating it. With annotations, you are
constantly reminded of the stuff.

> Then the schema has to be correct... so to add or change stuff one needs
> to :
>
> 1- add the field in the jdnc package
> 2- write the mapping logic in another file in the markup package
> 2a - give up ;-)
> 3- update the schema
> 4- check that all works well

The question has got to be where you are trying to save time. Schemas are
nice because the tools for validating them are very general, only tied
together for a given problem--you don't write your own. With the
annotations, somehow you have to validate that the mapping is still right,
and you have to maintain those tests. You can also publish a schema,
render it as HTML, DocBook, yadayada all of which you can't do with a
custom annotation-based scheme without writing your own tools to do so.

> Well, ATM we have a set of classes in the markup packages that do the
> mapping. If they were in the jdnc code instead, it would be easier to
> maintain. A schema can still be kept, just as now.

Well, easier in terms of quicker to change. But also quicker to break...

> For memory, I doubt that we will have multi-megabyte files to parse.
> IMHO the speedup of the use of SAX instead of DOM in this case is
> neglible... in any case it has to be tried with real code before really
> knowing it ;-)

Agreed. It's probably a red herring.

>
>
> IMO classes can be much faster than XML to load.
> Try taking a moderately Serializable complex object tree and serialize
> it, and them serialize it in XML... I usually find that the XML version
> is much much slower in coming up.
>

I've heard this argued both ways, don't know, myself.

Regards
Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net