You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Ted Moens <tm...@telus.net> on 2007/12/12 12:21:07 UTC

XML Mapping File

Greetings:

I'm using Cayenne 3.0M2 on Vista.

I am trying to create some XML to represent data in my database.  I was 
unable to find clear documentation on the file format and usage for the 
XML Mapping File that guides the generation, though this page is 
tantalizing:

http://cwiki.apache.org/confluence/display/CAY/XML+Mapping+File
XML Mapping File - Apache Cayenne - Apache Software Foundation

and the example files in this issue were helpful too:

https://issues.apache.org/cayenne/browse/CAY-597
[#CAY-597] XML Encoder with Mapping outputs incorrect XML - Apache 
Cayenne Issue Tracker

In any case, I have pretty much figured out how to do what I want with 
the mapping file and I find it *extremely* easy and straight forward. 
Here comes the BUT....

1) if one does not define the properties of an object explicitly in the 
Mapping file, Cayenne does its best and outputs all the scalar 
properties or an object in the XML Example:

<lastUpdate type="java.util.Date">2007-12-10 09:34:00 PST</lastUpdate>

If one does define the same property using the <entity> ... <property 
.../> ... </entity> tags, Cayenne will output it like so:

<lastUpdate>2007-12-10 09:34:00 PST</lastUpdate>

So, in one case type information is lost and in the other it is 
maintained.  Is there a reason for this?  Is there a way to get Cayenne 
to output the type information always?

2) collections/lists - is there any way to use the mapping file to cause 
the XML to group a set of recurring elements?  That is, I would like:
...
<country>
...
	<cities>
		<city .../>
		<city .../>
		...
		<city ...>
	</cities>
...
</country>
...

Rather than what I am getting, namely:
...
<country>
...
	<city .../>
	<city .../>
	...
	<city ...>
...
</country>
...


Kind regards,

Ted Moens

Re: XML Mapping File

Posted by Kevin Menard <km...@servprise.com>.
Hi Ted,

Comments are in-line.


On 12/12/07 6:21 AM, "Ted Moens" <tm...@telus.net> wrote:
 
> 1) if one does not define the properties of an object explicitly in the
> Mapping file, Cayenne does its best and outputs all the scalar
> properties or an object in the XML Example:
> 
> <lastUpdate type="java.util.Date">2007-12-10 09:34:00 PST</lastUpdate>
> 
> If one does define the same property using the <entity> ... <property
> .../> ... </entity> tags, Cayenne will output it like so:
> 
> <lastUpdate>2007-12-10 09:34:00 PST</lastUpdate>
> 
> So, in one case type information is lost and in the other it is
> maintained.  Is there a reason for this?  Is there a way to get Cayenne
> to output the type information always?

If you do not provide a mapping file, you must implement the XMLSerializable
interface.  As a convenience, CayenneDataObject implements this interface
for you and uses introspection to map your declared attributes.

If you implemented the interface yourself, however, you could encode/decode
arbitrary properties.  Here, the type information is required to generate
the proper type.

With the mapping file, you have associated properties and we can figure out
the type as we decode so there's generally no need to explicitly specify it.
Where it is needed, it's provided in the mapping file, not in the serialized
document.

If this something you'd like to see added, I'd recommend opening up a JIRA
issue.  We could probably add a new attribute to the mapping file to support
this. 

> 
> 2) collections/lists - is there any way to use the mapping file to cause
> the XML to group a set of recurring elements?  That is, I would like:
> ...
> <country>
> ...
> <cities>
> <city .../>
> <city .../>
> ...
> <city ...>
> </cities>
> ...
> </country>
> ...
> 
> Rather than what I am getting, namely:
> ...
> <country>
> ...
> <city .../>
> <city .../>
> ...
> <city ...>
> ...
> </country>

The only way to do that currently is if you added a new path element to your
bean.  The List structure is inferred based on the multiple entries.  If
it's something you'd like to see, I'd suggest opening up a new JIRA issue.

-- 
Kevin