SV: [jdom-interest] Life or death of the Parent interface

[Phil Weighill-Smith]

Because of the way we use JDOM (we specialize Element, Attribute, CDATA
and Text) in order to make an "observable" DOM (cf. JavaBeans and
Property Change Listeners, but with notification up the hierarchy too),
we've had to make specific use of various methods (such as setAttribute,
setParent etc.) to generate the required change events.

This means we're quite sensitive to external and internal API changes.

However, one change that I think would be very useful is to have a
(placeholder) interface, such as Node, that all of these classes
implement. This would be *much* nicer than Object as the common class.

It seems to me that all nodes have the concept of a parent, so perhaps
this interface is equivalent to your Child interface...?

Phil :n.

On Fri, 2004-02-20 at 23:06, Per Norrman wrote:

> Hi,
> 
> There definitely is some merit in the Parent/Content constructs, BUT,
> the problem is that you'll be breaking a lot of existing code with 
> the introduction of Parent and the behavioural change of addContent
> et al. Perhaps method chaining isn't the best idiom around, but after 
> *four* years it's become somewhat of a JDOM signum. Not all people will
> be happy ....
> 
> I just think it's too late in the game to introduce conceptual changes
> like this. MHO.
> 
> /pmn
> 
> 
> > -----Ursprungligt meddelande-----
> > Från: jdom-interest-admin at jdom.org 
> > [mailto:jdom-interest-admin at jdom.org] För Jason Hunter
> > Skickat: den 20 februari 2004 21:03
> > Till: jdom-interest at jdom.org
> > Ämne: [jdom-interest] Life or death of the Parent interface
> > 
> > 
> > So people seem to like the Content abstract class, but 
> > there's been some 
> > pushback on the Parent interface.  Some have suggested removing the 
> > interface entirely.  I'm wondering if that might be best.
> > 
> > Its main purpose right now could be described as a generic type for 
> > setParent() to take and getParent() to return.  There's also 
> > the benefit 
> > when learning the API that you quickly see how Document and Element 
> > share a core set of methods.  Those benefits are nice, but really not 
> > critical.
> > 
> > What people don't like is that now the various Parent methods -- 
> > addContent, setContent, getParent -- return Parent instead of the 
> > specific Element or Document type on which they're acting.  
> > By removing 
> > Parent we could fix that and simplify the API by one class.  
> > We'd just 
> > change getParent/setParent to use Object.  As another 
> > secondary perk, we 
> > would avoid the Parent/Content odd naming convention.
> > 
> > In the end I don't think this is a critical design issue one 
> > way or the 
> > other, but I'd like to make sure the situation is fully understood 
> > before deciding.
> > 
> > Am I right in classifying the pros/cons of each proposal?  Is the 
> > biggest complaing about Parent how it reduces the ability to chain? 
> > What about the lost ability to chain a 
> > getParent().getParent() sequence?
> > 
> > -jh-
> > 
> > _______________________________________________
> > To control your jdom-interest membership: 
> > http://lists.denveronline.net/mailman/options/jdom-interest/yo
> uraddr at yourhost.com
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Phil Weighill-Smith <phil.weighill-smith at volantis.com>
Volantis Systems
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20040223/aafb5bc5/attachment.htm