axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Venkat Reddy <vred...@gmail.com>
Subject Re: [Axis2] Need for children API for OMDocument
Date Fri, 03 Jun 2005 09:29:49 GMT
I suggest we go with Document extend OMElement to resolve this until
next refactoring of OM. WDYT?

On 6/3/05, Venkat Reddy <vreddyp@gmail.com> wrote:
> just saw some more issues if we go with new Interface.
> 
> The client API 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.
> 
> If we add a new method SOAPFactory.createOMParent(), then the entire
> client API has to deal with OMParent objects instead of OMElement
> objects while building the message, which looks weird.
> 
> - Venkat
> 
> 
> On 6/2/05, Eran Chinthaka <chinthaka@opensource.lk> wrote:
> > Didn't I gave my +1 for this. Ok here goes, +1 ;).
> >
> > -- Chinthaka
> >
> > > -----Original Message-----
> > > From: Venkat Reddy [mailto:vreddyp@gmail.com]
> > > Sent: Thursday, June 02, 2005 10:55 AM
> > > To: axis-dev@ws.apache.org
> > > Subject: Re: [Axis2] Need for children API for OMDocument
> > >
> > > Not another class, but OMElementImpl need to implement the new
> > > interface and all the child API be moved from OMElement to OMParent.
> > > Also note that OMNode.setParent() now receives OMPraent, instead of
> > > OMElement.
> > >
> > > So the result is - OMDocument now implements only child navigation API
> > > and avoids stuff like namaespaces and attributes. +1.
> > >
> > > - venkat
> > >
> > > On 6/2/05, Eran Chinthaka <chinthaka@opensource.lk> wrote:
> > > > I'm ok with having an "interface" for parent, but not another class.
> > > >
> > > > -- Chinthaka
> > > >
> > > > > -----Original Message-----
> > > > > From: jayachandra [mailto:jayachandra@gmail.com]
> > > > > Sent: Wednesday, June 01, 2005 7:32 PM
> > > > > To: axis-dev@ws.apache.org
> > > > > Subject: Re: [Axis2] Need for children API for OMDocument
> > > > >
> > > > > While duplicating the child API into OMDocument I got stuck at
> > > something.
> > > > > The addChild() method of in turn tries to setParent(), and the
> > > > > datamember parent is rigidly typed to be an OMElement only.
> > > > >      /**
> > > > >      * Field parent
> > > > >      */
> > > > >     protected OMElementImpl parent;
> > > > >
> > > > > Now that OMDocument can also be a parent other than just OMElement,
my
> > > > > suggestion would be to have a wrapper interface OMParent that contains
> > > > > in it the child API methods ( 6 of them). Its good to have child
> > > > > navigation API within OMParent than anywhere else (currently it's
in
> > > > > OMElement). Subsequently OMElementImpl class and OMDocument class
if
> > > > > they implement this OMParent all the existing code will remain to
be
> > > > > intact with the additional desired functionality that OMDocument
can
> > > > > hold multiple entities in it.
> > > > >
> > > > > Thanks
> > > > > Jaya
> > > > >
> > > > > My idea boils down to something like
> > > > >
> > > > > //child navigation API methods will be shifted from OMElement to
> > > > > OMParent interface
> > > > > public interface OMParent {
> > > > >   public void addChild(OMNode omNode);
> > > > >   public Iterator getChildrenWithName(QName elementQName) throws
> > > > > OMException;
> > > > >   public OMElement getFirstChildWithName(QName elementQName) throws
> > > > > OMException;
> > > > >   public Iterator getChildren();
> > > > >   public void setFirstChild(OMNode node);
> > > > >   public OMNode getFirstChild();
> > > > > }
> > > > >
> > > > > //OMElementImpl should implement OMParent
> > > > > public class OMElementImpl extends OMNodeImpl implements
> > > OMParent,...{...}
> > > > >
> > > > > //OMDocument should implement OMParent
> > > > > public class OMDocument implements OMParent {...}
> > > > >
> > > > > //The parent datamember in OMNodeImpl will be typed as OMParent type
> > > > > public class OMNodeImpl implements OMNode {
> > > > > ...
> > > > > protected OMParent parent;  // << parent should no longer be
> > > OMElementImpl
> > > > > type
> > > > > ...
> > > > > ...
> > > > > }
> > > > >
> > > > > Thank you
> > > > > Jayachandra
> > > > >
> > > > > On 6/1/05, jayachandra <jayachandra@gmail.com> wrote:
> > > > > > Yeah! that's a wise way rather than extending OMElement. Apart
being
> > > > > > more clear on the readability front it also reduces unnecessary
> > > > > > placeholders from creeping into OMDocument.
> > > > > >
> > > > > > Jaya
> > > > > >
> > > > > > On 6/1/05, Aleksander Slominski <aslom@cs.indiana.edu>
wrote:
> > > > > > > jayachandra wrote:
> > > > > > >
> > > > > > > >Can someone respond on this, plz.
> > > > > > > >
> > > > > > > >
> > > > > > > why not model it exactly as it is in XML Infoset - so have
> > > children
> > > > > API
> > > > > > > but do not extend OMElement just duplicate it (AFAICT Document
is
> > > not
> > > > > > > Element ...)
> > > > > > > http://www.w3.org/TR/xml-infoset/#infoitem.document
> > > > > > >
> > > > > > > alek
> > > > > > >
> > > > > > > >Thanks
> > > > > > > >Jaya
> > > > > > > >
> > > > > > > >On 5/31/05, jayachandra <jayachandra@gmail.com>
wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >>Hi devs,
> > > > > > > >>
> > > > > > > >>I have two suggestions regarding OMDocument
> > > > > > > >>
> > > > > > > >>First - a trivial one:
> > > > > > > >>---------------------------
> > > > > > > >>It lacks an interface definition in the package
> > > org.apache.axis.om
> > > > > and
> > > > > > > >>a direct implementation class with name OMDocument.java
is coded
> > > in
> > > > > > > >>the o.a.a.om.impl.llom package. In line with how
rest of the
> > > code is
> > > > > > > >>arranged, I suggest we have in o.a.a.om package
an interface
> > > with
> > > > > name
> > > > > > > >>OMDocument.java listing out the setter and getter
methods for
> > > > > > > >>rootElement. And in the OMFactory interface we
will add an extra
> > > > > > > >>signature something like createOMDocument so as
to enable other
> > > than
> > > > > > > >>llom factory to be able to provide OMDocument implementation.
> > > Let
> > > > > the
> > > > > > > >>implementation class in impl.llom package be named
as
> > > > > > > >>OMDocumentImpl.java
> > > > > > > >>
> > > > > > > >>Second - this is a critical design issue:
> > > > > > > >>--------------------------------------------------------
> > > > > > > >>Looking at the current OMDocument support I've
realized that it
> > > > > > > >>doesn't have a child navigation API. We might be
doing away
> > > without
> > > > > it
> > > > > > > >>as far as soap processing is considered. But without
the child
> > > > > > > >>navigation API in it, XMLInfoset can never be fully
supported
> > > > > because
> > > > > > > >>in an XML document other than the unique root element,
at the
> > > same
> > > > > > > >>level we can have several other nodes like documentation
> > > comments,
> > > > > > > >>processing instructions, DTD element etc.
> > > > > > > >>Enabling child API in OMDocument, implementation
wise is not any
> > > > > > > >>difficult. It can be just making it extend OMElement.
Something
> > > like
> > > > > > > >>public interface OMDocument extends OMElement ;
> > > > > > > >>
> > > > > > > >>Semantically if the above looks confusing and weird
(OMDocument
> > > > > being
> > > > > > > >>an OMElement !!??!!), alternatively we can copy
paste the
> > > already
> > > > > > > >>coded child API functionality of OMElementImpl
into
> > > OMDocumentImpl
> > > > > > > >>letting OMDocument to stand on its own without
extending any
> > > other
> > > > > > > >>interface. Also, performance wise these changes
are not going to
> > > add
> > > > > > > >>any significant overhead.
> > > > > > > >>
> > > > > > > >>Anticipating thoughts, ideas, suggestions
> > > > > > > >>
> > > > > > > >>Regards
> > > > > > > >>Jaya
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > The best way to predict the future is to invent it - Alan
Kay
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > -- Jaya
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > -- Jaya
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> >
>

Mime
View raw message