Eric Johnson wrote:
> Eran Chinthaka wrote:
>
>> Steve Loughran wrote:
>>
>>
>>
>>> On the subject of data binding, it would suit me nicely if you could
>>> easily build an OMElement graph from a DOM or SAX tree.
>>>
>>
> I believe there is a "SAX" builder for AXIOM trees. I don't think
> there is any test code for it, and having looked at the code, I
> suspect it doesn't work right, at least not always. If you can find a
> DOM to SAX adapter, then Axis is already almost there.
hmm. Well, if the test case is not enough lets fix the test case first
and improve the SAX to StAX conversion code.
>
> Maybe I don't understand your question either.
>
>>
>> What do you mean here ? Are you asking for a special OMElement which
>> wraps any data binding object, as Dennis explained.
>>
>>
> [snip]
>
>> BTW, you all agree that the only missing "feature" we should have in
>> Axis2, for it to be promoted for 1.0 status, is Axis2 own databinding
>> implementation. I think Ajith has almost completed XMLBeans integration.
>>
>> So lets have a broader discussion on this.
>>
>> One of the concerns raised in the last chat is the integration of data
>> bound object to OM.
>>
>> So as I see there are two ways;
>>
>> 1. Getting pull parser from the data bound object, irrespective of which
>> framework was used to data bound, and create an OMElement out of it and
>> hangs that to the OM tree.
>>
>> DataBoundObject dbObj = // get the data bound object
>> OMElement dbObjWrapper = new
>> StaxOMBuilder(dataBoundObject.getPullParser()).getDocumentElement();
>>
>> // add this to body of wherever you want
>> body.addChild(dbObjWrapper);
>>
>> 2. Giving the data bound object an XSR (XMLStreamWriter) and ask him to
>> serialize himself
>> DataBoundObject dbObj = // get the data bound object
>> SpecialOMElement dbObjContainer = new SpecialOMElement(dbObj);
>> dbObjContainer.serialize(xmlStreamWriter);
>>
>> (are there other approaches ? if so please comment)
>>
>>
> Perhaps yes, there are other approaches. Or maybe this is what you're
> getting at with your second proposal here? How about setting it up so
> that serialization is (normally) done externally to the object
> itself. That implies that the "data bound object", as you refer to
> it, has Java Bean semantics, or some such, in that there would need to
> be "getters" for every property that might be serialized (or package
> protected members).
This is exactly what we do in the first approach. The ADBPullParser is
the util containder you are trying to explain.
When you give a bean, ADBBean or an OMElement, it will generate the pull
events. But we made the ADBBean a special case by having a method inside
the ADBBean to get the pull parser. Actually, within this method the
ADBBean delegates the functionality to the ADBPullParser.
Let me explain why we have to do this for ADBBean. ADBBean is a simple
java bean. If ADBBean has three attributes, how do you consider them ?
As attributes or as child elements ? all depends on the schema.
So you can not simply give an ADBBean to your util and ask him to write
the bean, or get a reader. Thats why we created the ADBPullParser
"within" the ADBBean itself.
So merging all the discussions, the argument biols down to who has the
control. So I can provide a method in ADBPullParser, so that you can do
some thing like this.
ADBPullParser adbPullParser = new ADBPullParser(qName, propertyList,
attributeList);
adbPullParser.serialize(xmlStreamWriter);
the implementation will be as follows.
if(object instanceof ADBBean){
// get a pull parser from adbBean and write that to the given xmlSR
}else if(object instanceof OMElement){
((OMElement)object).serialize(xmlSR)
}else if(object instanceof Bean){
// get a pull parser from the bean and serialize it to the xmlSR
}else {
// this should be one from other data binding tools. Give the xmlSR
to that object and ask him to serialize himself
}
I'm proposing this from the points taken from Eric and Dennis.
-- Chinthaka
