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
