Re: JiBX Databinding: databinding interface methods

[Dennis Sosnoski <dm...@sosnoski.com>]

On 07/22/2010 02:16 PM, Daniel Kulp wrote:
> On Wednesday 21 July 2010 5:19:42 pm Dennis Sosnoski wrote:
>   
> ...
>> And in
>> that case I assume the runtime DataBinding object must implement
>> WrapperCapableDatabinding, right? (Since otherwise I don't see how the
>> unwrapping could be handled).
>>     
> Well, yes and no.   It should implement it if possible.    If not, what 
> happens at runtime is that the WrappedInInterceptor would strip off the 
> wrapper element and it would try and call into the databinding to read each 
> individual part directly.   In some cases, this can be a bit slower as the 
> databinding needs to set things up and such for each part instead of for the 
> entire payload at once.   
>   

So as long as the databinding code can efficiently process multiple
child elements one-at-a-time it's feasible to skip generating classes
for the wrapper elements and instead just generate the data model? Then
the WrappedInInterceptor would create a DataReader<T> instance for each
child element of the wrapper, and call one of the read() methods?

So does the WrappedInInterceptor know which type of DataReader<T> to
create for each child element type by calling (at code generation time)
the DataBindingProfile String getType(QName qn, boolean element) method?

It sounds like we could use either approach with JiBX - generate classes
for the wrapper elements, and support the DataBindingProfile String
getWrappedElementType(QName wrapperElement, QName item) method call to
provide code-generation-time information about the child element
components *and* also generate WrapperHelper classes to get data in and
out of the wrappers, or only generate the actual data classes and let
WrappedInInterceptor handle the details. Since generating the
WrapperHelper classes adds a fair amount of complexity, I'm thinking the
latter approach might be better.

  - Dennis

Re: JiBX Databinding: databinding interface methods

[Daniel Kulp <dk...@apache.org>]

On Saturday 07 August 2010 3:41:15 am Dennis Sosnoski wrote:
> On 07/22/2010 02:16 PM, Daniel Kulp wrote:
> > On Wednesday 21 July 2010 5:19:42 pm Dennis Sosnoski wrote:
> > 
> > ...
> > 
> >> And in
> >> that case I assume the runtime DataBinding object must implement
> >> WrapperCapableDatabinding, right? (Since otherwise I don't see how the
> >> unwrapping could be handled).
> > 
> > Well, yes and no.   It should implement it if possible.    If not, what
> > happens at runtime is that the WrappedInInterceptor would strip off the
> > wrapper element and it would try and call into the databinding to read
> > each individual part directly.   In some cases, this can be a bit slower
> > as the databinding needs to set things up and such for each part instead
> > of for the entire payload at once.
> 
> So as long as the databinding code can efficiently process multiple
> child elements one-at-a-time it's feasible to skip generating classes
> for the wrapper elements and instead just generate the data model? Then
> the WrappedInInterceptor would create a DataReader<T> instance for each
> child element of the wrapper, and call one of the read() methods? 

Yep.  That's how Aegis works.

> So does the WrappedInInterceptor know which type of DataReader<T> to
> create for each child element type by calling (at code generation time)
> the DataBindingProfile String getType(QName qn, boolean element) method?

No.  It passes the MessagePartInfo object into the reader for the part.   From 
there, the Databinding can figure out whatever it needs to do.   If it needs 
to call getType, it can.  If it has other ways to handle it, great.


> It sounds like we could use either approach with JiBX - generate classes
> for the wrapper elements, and support the DataBindingProfile String
> getWrappedElementType(QName wrapperElement, QName item) method call to
> provide code-generation-time information about the child element
> components *and* also generate WrapperHelper classes to get data in and
> out of the wrappers, or only generate the actual data classes and let
> WrappedInInterceptor handle the details. Since generating the
> WrapperHelper classes adds a fair amount of complexity, I'm thinking the
> latter approach might be better.

If it works, then yea.


-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog