I suggest we go with Document extend OMElement to resolve this until next refactoring of OM. WDYT?
On 6/3/05, Venkat Reddy <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > Didn't I gave my +1 for this. Ok here goes, +1 ;). > > > > -- Chinthaka > > > > > -----Original Message----- > > > From: Venkat Reddy [mailto:[EMAIL PROTECTED] > > > 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 <[EMAIL PROTECTED]> wrote: > > > > I'm ok with having an "interface" for parent, but not another class. > > > > > > > > -- Chinthaka > > > > > > > > > -----Original Message----- > > > > > From: jayachandra [mailto:[EMAIL PROTECTED] > > > > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > > > > > > > > > > > > > > > > > > > > > > >
