Venkat Reddy wrote:
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.
well as far as I can tell it is going to work OK if OMElement extends
OMContainer ...
OMContainer will replace OMElement all over the
client programming.
why? for example?
The other not-so-good alternative is to typecast
OMElement to OMElementImpl and then call addChild, because
OMElementImpl implements OMContainer.
i see no reason to do that.
alek
- 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.
--
The best way to predict the future is to invent it - Alan Kay
