Hi Sanjiva,
Thanks for the comment.
Yes, there are different cases here.
Case 1) The underlying Object provides the QName.
Case 2) The underlying Object does not provide the QName, The QName must be provided separately.
Case 3) The underlying Object provides the QName, but it can be overriden.
I agree that these cases need to be considered by the implementation classes of the OMObjectWrapper.
------------------
This forces an additional methods onto the proposed OMOW.
public interface OMObjectWrapper(){
public XMLStreamReader getPullParser();
public void writeYourSelf(XMLStreamWriter);
/**
* @return QName of the element. The QName is used to set the OMNamespace when the OMOWE is constructed.
*/
public QName getQName();
}
------------------
public class OMObjectWrappingElement extends OMElement{
public OMObjectWrappingElement(OMObjectWrapper wrapper){
...construct OMNamespace using wrapper.getQName()....
}
public void serializeWithConsume(XMLStreamWriter writer){
wrapper.writeYourSelf(writer)
}
}
----------------
Sanjiva, does this mesh with your ideas.
Thanks,
Rich Scheuerle
Sanjiva Weerawarana <[EMAIL PROTECTED]>
06/17/2006 08:18 AM
|
|
On Sat, 2006-06-17 at 07:53 -0500, R J Scheuerle Jr wrote:
> My concern is that the OMOWE is not like a normal OMElement. It will
> not have a Namespace when it is constructed.
> (To get the namespace/localpart, the implementation would need to
> examine the underlying Object...which would cause a serialization (for
> JAXB)...
> which defeats the whole effort...)
I don't like that model .. why not say that any subclass of OMElement
*must* be an honest-to-goodness OMElement .. which means that it MUST
have a QName. So we can just have the constructor take that as input ..
that way the same object can be serialized as different QNames even.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

