Raymond Feng wrote:
Please see comments inline.
Raymond
----- Original Message ----- From: "Jean-Sebastien Delfino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, November 17, 2007 9:59 AM
Subject: Re: Data transformation from/to POJO
Raymond Feng wrote:
Hi,
With the recent development of the online store tutorial, we
encounter quite a few issues around the transformation between POJO
and other databindings (such as XML, JSON).
Yeah :)
Let's take the POJO <--> XML as an example. Here is a set of
questions to be answered.
1) Do we require the POJO to be a strict JavaBean or free-form class?
2) How to read properties from a java object?
The data in a java object can be accessed by the field or by
JavaBean style getter methods. There are different strategies:
a) Always use JavaBean-style getter method
b) Always use field access
c) A combination of a & b
The other factor is the modifier of a field/method defintion. What
modifiers are allowed? public, protected, default and private?
If a property only have getter method, should we dump the property
into the XML? How about transient fields?
3) How to write properties to populate the target POJO instance?
a) Use JavaBean setter?
b) Use field
c) Combination of a & b
Can't we just follow the SDO or JaxB spec?
I don't think that's the case. Both SDO and JAXB have addtional
metadata to help make the decision but POJOs don't. SDO has the
Type/Property while JAXB uses annotations.
When we convert XML element back to a POJO property, how do we
instantiate the property instance if the property type is an
interface or abstract class?
For example,
package com.example;
public class MyBean {
private MyInterface p1;
public void setP1(MyInterface p1) {
this.p1 = p1;
}
public MyInterface getP1() {
return p1;
}
}
This goes beyond simple POJOs.
Are you saying we shouldn't support that? One simple case would be how
do we marshal an Exception into XML.
I'm looking at a typical application like the store tutorial and I don't
really see a use case for flowing an exception in an Atom entry for example.
Remember, I am just trying to represent and flow simple business objects
like the Item bean that I'm using in the ShoppingCart and Catalog
service, I'm not asking for a generalized databinding that can cover all
possible cases and flow anything that can be represented in the Java
language. We already have a ton of sophisticated data bindings like SDO
and JaxB for that.
Do we require the XML element contains xsi:type attribute which will
be generated from POJO-->XML to represent the concrete property
type? Such as:
<myBean xsi:type="ns1:MyBean" xmlns:ns1="http://example.com/";>
<p1 xsi:type="ns2:MyInterface" xmlns:ns2=http://example.com//>
</myBean>
Is the idea to support inheritance?
Yes.
Ah, OK, I was not sure about what you were trying to do with xsi:types.
So the good news is that I don't need inheritance in my use case. So if
we can keep the XML simple without all this xsi:type stuff everywhere
it'll be better.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
