Venkat Reddy wrote:
Oh, boy! this is not to suggest huge changes, as jaya said :-) You
guys already did enourmous work in designing this stuff. I'm just
trying to see if some api changes would make more sense.
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 ...
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 ...
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 ...
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 ...
alek
On 4/19/05, Ajith Ranabahu <[EMAIL PROTECTED]> wrote:
Hi,
Yes I have to admit that "time to time tweaking" has corrupted OM to a
certain extent. For starters I am not happy about the serilizing code and
planning to rewrite it (without putting you guys in trouble ofcourse :)) May
be I can team up with Chinthaka and go through the OM hierarchies to find
inconsistancies and fix them. You input is also much welcome.
BTW I also agree that this is the best time to tackle this problem. If we go
on further it will be harder to modify.
On 4/19/05, jayachandra < [EMAIL PROTECTED]> wrote:
As seen by Venkat, I too feel there is a serious lack of role
definitions and proper design when it comes to OM code (viz. OMNode
not doing the supposed tree manipulation stuff, OMElement deviating
from its semantics to do tree manipulation stuff and other such
anamolies). May be a detailed mail (by Venkat?) explaining all such
things and with due emphasis on good design practices can help us
refactor the code fully. We better do that refactoring as early as
possible rather regret in the end after the code base grows gigantic
beyond refactoring.
Awaiting a detailed mail from Venkat!
Bye
Jaya
--
Ajith Ranabahu
--
The best way to predict the future is to invent it - Alan Kay
