[jdom-interest] Parents - why do we need them?

[Szegedi, Attila]

This idea could work if JDOM were architected as a set of interfaces +
default implementations. In that scenario, if Element were an interface, one
could have a JTextBox subclass that also implements the Element interface -
a JDOM aware JTextBox (don't get me wrong - I do not favor the actual idea
of crossing Swing with JDOM on controller level, this is just an example
used in previous posts). If that gets passed to a JDOM method, it would
certainly be a conscious decision on behalf of the developer, not a mistake
that should be indicated by throwing an exception.

Now that JDOM uses factories all over instead of direct instantiation
through "new", I really see no obstacle to separation of JDOM into
interfaces (org.jdom.Element, org.jdom.Attribute, org.jdom.Document, etc.)
and default implementations (org.jdom.impl.ElementImpl,
org.jdom.impl.AttributeImpl, org.jdom.impl.DocumentImpl, etc.) I don't see
that being API bloating. Conversely, I see it as an opportunity for people
to write their specialized Element etc. classes from scratch instead of
necessarily subclassing existing JDOM classes.

Opinions?

Attila.


> -----Original Message-----
> From: jdom-interest-admin at jdom.org
> [mailto:jdom-interest-admin at jdom.org]On Behalf Of Elliotte
> Rusty Harold
> Sent: Tuesday, July 03, 2001 3:57 PM
> To: jdom-interest at jdom.org
> Subject: RE: [jdom-interest] Parents - why do we need them?
>
>
> At 2:43 PM -0500 7/1/01, philip.nelson at omniresources.com wrote:
>
> >Here is another idea, definately not thought through but I
> throw it up for
> >discussion.  One of the great unresolved parts of the api is
> the null and
> >bad type addtion problem with the lists.  We are assuming
> that the best idea
> >is to filter these out on the insertion.  Yet this idea of a shared
> >attribute, points to another idea.  What if the default
> behaviour of the
> >outputters was to ignore anything that wasn't a core JDOM
> class/subclass.
> >Nulls? disregard.  JTextBox? disregard.  Take the unhandled
> branch of the
> >outputter iteration one step further though and allow for a
> custom renderer
> >to be plugged in and a whole new range of patterns becomes possible.
> >
>
> NO! NO! NO! Are we really just filtering them out? How awful,
> whether we do it on insertion or output. If a JTextBox is
> getting added to an Element, then something very weird is
> going on. We need to alert the developer of this in the
> standard Java way by throwing an exception, possibly a
> runtime exception since this is so weird, but definitely we
> should throw an exception. We should not sweep the problem
> under the rug by letting it silently fail.
> --
>
> +-----------------------+------------------------+-------------------+
> | Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
> +-----------------------+------------------------+------------