No. OMDocument is a class
On 6/25/05, Aleksander Slominski <[EMAIL PROTECTED]> wrote:
> Venkat Reddy wrote:
>
> >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
> >
> >
> implements? OMDocument is not an interface?
>
> alek
>
> >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.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >
> >
> >
>
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
--
-- Jaya
