Eran Chinthaka wrote:
Good Effort Venkat. See my comments below.
Not any burning issues; i'm just thinking aloud while going through the
code.
- methods in OMElement and OMNode seem a bit mixed up. The
getter/setter methods for parent and siblings are available in OMNode
and they use OMElement and OMNode respectively. The getter/setter
methods for children are available on OMElement and they use OMNode.
The reason for this comes from the architecture of OM itself. Parent can
only be an OMElement. OMElement can have OMNodes as children, which happens
to be OMElement and OMText. We have to *fully* preserve the infoset. So we
must maintain the text and elements order as well. So in the linked list
implementation of OM we maintain these as a linked list of OMNodes. So
getter/setter methods for children are always using OMNode.
Actually the confusion exists in SAAJ itself, where
javax.xml.soap.Node has setParent and getParent using SOAPElement. May
be i didn't understand the role of these two interfaces. However
org.w3c.dom seem to have clear roles for Node and Element.
- setParent* methods SAAJ and adppendChild in DOM detach node from the
currrent parent first. OM implementations for these methods do not
detach node, and might end up in having multiple parents.
Thankx. It was a mistake. I fixed that.
Also
setParent looks redundant when we have appendChild methods doing the
same (applies to SAAJ also).
Well you have the two ways to do the same thing. ;)
- Almost all Impl classes "implement" OMConstants, may be to optimize
the access to the constants, but might reduce the clarity of code.
Well I thought this is a normal practice. For example, rather than saying,
OMConstants.XXXXX, XXXX is more straight forward. This came from my
experience. One would say, this is some sort of misuse of interfaces. But
.....
I think we are taking a bold step by defining OM as our own Axis
specific alternative to DOM and SAAJ to give us performance, which is
very refreshing and exciting too.
Yeah, sure. I think we must be proud of our OM (at least I do). We are the
first to implement an object model with differed building still with very
good performance. We have proved that.
XPP2 had this capability few years before OM and i am happy to see that
AXIS2 will now have it.
The best way to predict the future is to invent it. (Thankx Alek ;))
yes - it is the most interesting part of during software for me: one of
domains where one can explore new horizons and see current "cutting
edge" becoming "outdated" in few years ...
alek
--
The best way to predict the future is to invent it - Alan Kay
