For example, userguide.clients.ClientUtil.getEchoOMElement() uses the
following syntax to build the message.
OMFactory fac = OMAbstractFactory.getOMFactory();
OMNamespace omNs =
fac.createOMNamespace("http://example1.org/example1";, "example1");
OMElement method = fac.createOMElement("echo", omNs);
OMElement value = fac.createOMElement("Text", omNs);
value.addChild(fac.createText(value, "Axis2 Echo String "));
method.addChild(value);
If the addChild method is moved from OMElement to OMContainer, this
syntax doesn't work. OMContainer will replace OMElement all over the
client programming. The other not-so-good alternative is to typecast
OMElement to OMElementImpl and then call addChild, because
OMElementImpl implements OMContainer.
- venkat
On 6/24/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-06-24 at 13:03 +0530, Venkat Reddy wrote:
> > Alek,
> >
> > Like i said in the earlier thread on the same subject, there are
> > couple of issues if we move the child API from OMElement to a seperate
> > interface. The excerpt from my old mail:
> >
> > "The client API currently uses OMElement.addChild() to build the
> > message. Even if
> > we try to use setParent() instead of addChild() here, the user has to
> > typecast the OMElement into OMElementImpl and pass it to setParent,
> > which is not elegant."
> >
> > Do have any ideas to resolve this? Until we get new ideas, here is my
> > +1 for OMDocument extends OMElement.
>
> Maybe I didn't understand it (I didn't follow the previous thread
> carefully) but if there's an OmContainer interface containing
> addChild(), getChild() etc. etc., then if
> interface OmElement extends OmContainer
> interface OmDocument extends OmContainer
> etc. then I'm not clear why one needs to do a cast. Can you expand
> please Venkat?
>
> Sanjiva.
>
>
>
