[jdom-interest] Child-Parent patch - Ideas.
jhunter at xquery.com
Thu Feb 5 17:52:54 PST 2004
New: I checked in Rolf's changes. You can do a diff between the CVS
tags "before_rolf" and "after_rolf" to see the effect of his changes.
The zips will also work.
I'd still like feedback. I just checked them in since they seem
reasonable to me.
Jason Hunter wrote:
> Rolf sent in this change a while back, and I just integrated it with the
> latest CVS code but haven't checked it in. I'm curious what other
> people think of it as an approach. Rolf's description below explains
> its justification.
> I invite people to compare the CVS HEAD (get it from CVS or at
> http://jdom.org/head.zip) versus the source at http://jdom.org/rolf.zip.
> Comments welcome. Which way should we go?
> Rolf Lear wrote:
>> I have had a look at the Child/Parent thing.
>> Personally, I don't think the Idea has been taken far enough, so I
>> played around with the concept, and "normalised" some of the
>> Firstly, I converted the Child interface into an Abstract class that
>> deals with ALL Parent/child relationships for the Child role,
>> including detaching, cloning, set/getParent (and holds the parent
>> instance field).
>> I also implemented getDocument at the Child Class level (all children
>> have the same mechanism for getting the Document).
>> Next, I added the method "getDocument" to the Parent Interface... and
>> parent can getDocument, including the Document class which has "return
>> this;" in the getDocument().
>> Finally, I changed the ContentList class substantially. elementData is
>> now called childData, and is of type Child instead of Object. The
>> ContentList owner is now of type Parent instead of Object. I have
>> added a method canContain to the Parent interface, and thus the actual
>> Parent object determines what content is allowed in the contentlist,
>> so instead of add(int,Text), add(int,Element), add(int,CDATA),
>> add(int,ProcessingInstruction), etc, there is just add(int, Child).
>> In doing all of the above, I have cut large amounts of
>> redundant/duplicated code, simplified the relationships, and thrown
>> away "special cases". The only downside I can see in terms of
>> "functionality" is that some of the exceptions are thrown with less
>> specialised messages...
>> Please have a look, and comment on the concept. Note, that this is
>> only possible by converting Child to an abstract class instead of an
> To control your jdom-interest membership:
More information about the jdom-interest