axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: [Axis2] Need for children API for OMDocument
Date Thu, 02 Jun 2005 02:00:02 GMT
jayachandra wrote:

>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 
>  
>
i am not sure if getChildrenWithName() is needed in OMDocument but 
otherwise i think it is good idea to have common "container" abstraction 
for both OMDocument and OMElement.

alek

>//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
>>
>>    
>>
>
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay


Mime
View raw message