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
