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] OMNodeImpl notes
Date Thu, 21 Apr 2005 07:41:21 GMT
On 4/19/05, Aleksander Slominski <aslom@cs.indiana.edu> wrote:
> Venkat Reddy wrote:
> 
> >Currently OMElement is doing most of tree manipulation and element
> >information management (attributes, namespace, tagname, children etc).
> >OMNode is also doing a bit of both through the api for sibling,
> >parent, detach, value, type, serialize etc.
> >
> >I thought, may be we can separate the roles cleanly for OMNode to
> >manipulate the tree and OMElement to take care of element specific
> >data and specialized tree api (getchildrenWithName etc).
> >
> >This will mean OMText also will also inherit the tree API to add
> >children, but we can restrict it inside OMText class, by throwing
> >OMException.
> >
> >
> that is *not* very intuitive and strange hack for Java programmers ...

Hmm, i would say that not having children is a requirement for OMText,
and not for OMNode.

On the other hand, child API is generic enough to go into OMNode than
be a specialization of OMElement for two reasons - The usecase of
OMDocument indicates that OMNode should support child API, and the all
those methods that i mentioned mostly operate on OMNode objects.

> 
> >I'm not sure about increase in memory foot print, as mentioned by
> >Alek.
> >
> devil is in details - it is tempting to have base OMNode implementation
> and have OMText extend it ...

Temptations result in associated costs ;-) OMText need not extend
something which is too heavy for it. It should just implement OMNode
to the extent it needs.

> 
> > The OMNode interface will be added with only a few new methods
> >but not any new data. The OMText class also need not implement any
> >additional data.
> >
> >The benefit of this change would be that - OMNode will get a clear
> >role and can be optimized independently. OMElement can focus on the
> >XML element specific activities.
> >
> >Actually all the child API methods in OMElement are dealing with only
> >OMNode, and so they seem to belong to OMNode.
> >
> >    public void addChild(OMNode omNode);
> >    public Iterator getChildren();
> >    public void setFirstChild(OMNode node);
> >    public OMNode getFirstChild();
> >
> >
> why not call it node OMChildrenManagement interface and have OMDocument
> and OMElement implement. no need for OMText to implement it ...

It works. Except that OMNode is still not well defined for its role
and the API for children, sibling and parent are scattered around all
the three interfaces.

> 
> >Well, this might make it look more like DOM, but nothing wrong in
> >taking the good things from it :-)
> >
> >
> IMHO Node is not good thing - it was a dual interface for languages that
> did not support OO so they could use one class to work with any type of
> node. the preferred interface for Java should be proper hierarchy of
> classes/interfaces and asking programmer to figure out which method are
> usable in given context so they do not throw OMException or return
> special error value is not making of easy to use API ...

I dont think Node is such bad thing to have as the root level
abstraction of a tree API. Also I feel an interface is designed for
more commonly used API by its derivatives and impls, but not for the
least common features. The balance is required to avoid duplication of
code and modularization of related API into same place.

- venkat

> 
> alek
>

Mime
View raw message