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 <[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
--
The best way to predict the future is to invent it - Alan Kay
