<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.9">
</HEAD>
<BODY>
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.<BR>
<BR>
This means we're quite sensitive to external and internal API changes.<BR>
<BR>
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.<BR>
<BR>
It seems to me that all nodes have the concept of a parent, so perhaps this interface is equivalent to your Child interface...?<BR>
<BR>
Phil :n.<BR>
<BR>
On Fri, 2004-02-20 at 23:06, Per Norrman wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>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@jdom.org
> [mailto:jdom-interest-admin@jdom.org] För Jason Hunter
> Skickat: den 20 februari 2004 21:03
> Till: jdom-interest@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:
> </FONT><A HREF="http://lists.denveronline.net/mailman/options/jdom-interest/yo"><U>http://lists.denveronline.net/mailman/options/jdom-interest/yo</U></A>
<FONT COLOR="#737373">uraddr@yourhost.com
_______________________________________________
To control your jdom-interest membership:</FONT>
<A HREF="http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com"><U>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com</U></I></A></PRE>
</BLOCKQUOTE>
<PRE><TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
-- <BR>
Phil Weighill-Smith <<A HREF="mailto:phil.weighill-smith@volantis.com"><U>phil.weighill-smith@volantis.com</U></A>><BR>
Volantis Systems
</TD>
</TR>
</TABLE>
</PRE>
</BODY>
</HTML>