If no more objections are raised, lets conclude the discussion with
following decisions:
1. Shift Child API from OMElement to OMContainer.
2. OMElement extends OMContainer
3. OMDocument implements OMContainer
4. Resolve Axis2 - 22 after these changes are made.
OM'ers, if this is OK with you, Jaya will go ahead and make the
changes, and close the task of integrating Infoset support.
- venkat
On 6/24/05, Venkat Reddy <[EMAIL PROTECTED]> wrote:
> hmm... my assumption is that OMElementImpl will implement both
> OMContainer and OMElement, but not OMElement extending OMContainer. If
> OMElement extends OMContainer, then it is OK - no problem.
>
> On 6/24/05, Venkat Reddy <[EMAIL PROTECTED]> 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. 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.
> > >
> > >
> > >
> >
>
