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.
I'm not sure about increase in memory foot print, as mentioned by
Alek. 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();
Well, this might make it look more like DOM, but nothing wrong in
taking the good things from it :-)
- venkat
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
