[jdom-interest] (no subject)

Thu May 29 10:31:14 PDT 2003

I somewhat agree. Having separate Parent and Child interfaces is more
"correct", but a single interface feels much more natural and intuitive
to me, for some reason. I wouldn't combine the two though, I'd just get
rid of Parent and rename Child to Node. I'm sure there are some times
when you want to treat the top level of a document in the same way you
treat all lower levels, but I think most of the time you just deal with
the root element on down instead. Plus, if you do need to handle all the
levels generically, the workaround is to grab the List of contents of
the Document and recurse from there.

Alex

>>> <Vadim.Strizhevsky at morganstanley.com> 5/29/2003 11:58:45 AM >>>

Having separate Parent and Child interfaces seems strange because in
most
cases (Element is the most common case) the same item is both Parent
and
Child. I almost think that you don't want this separation. I.e. have
some
interface "Item", that has both  getParent*() and getChild*() which
all
return Item(s).

If a particular Item doesn't have a parent, then getParent() should
return
null, same for children. The fact that something has or doesn't have a
parent seems more naturally determined by whether getParent() returns
null
and not by whether its type is "Child". As even in that case
getParent()
could still return null if its unatached. So you'd have to test both
whether its "Child" and whether getParent() is null.

I understand the motivation, that its weird to have Document have
getParent() function and Attribute have a getChild(), but is it really?
We
are just saying that those items don't have any parent or children by
having those function return null. I don't see the need to have a type
information indicate whether it can do this, especially if in many
cases
you're going to need to cast.

Having two separate Parent/Child intefaces is also very confusing, and
I
don't think really helps to treat the JDOM tree as a "generic" tree,
if
that was one of the goals. Because you have to do the casts below to
walk
the tree. What if you want to walk it down? You'd have to cast the
Child
returned by getChild* to Parent, before you can call getChild again?
Not very nice either. And if you start puting getParent() into Parent
and
getChild() into Child, than you'll wind up with the same interfaces
anyway.

Which brings me back to my suggestion of having a single "ParentChild"
interface. Call it whatever you want though. I think final cast to
Element/Attribute/Document is fine, but having to cast in chain,
whether
walking up or down the tree, is too weird.

just IMO, of course.

-Vadim

PS. I haven't looked at CVS code after B9, so I'm basing the above
comments solely on the mails. Forgive me if I misunderstood anything
about
the actual implementation.

On Thu, 29 May 2003, Jason Hunter wrote:

> We put getParent() in Child because children have parents.  Parents
> don't necessarily.  If the call were in Parent, only Document and
> Element would have the call.  We'd probably have to put it in both
> places to enable the method chaining as you'd like.  That's just
odd.
>
> Hmm, I'm still thinking we need a method like getParentElement().
> Returns the parent Element or null if root or unattached.  It could
be
> added to Child.  Then you could call
> getParentElement().getParentElement()...
>
> Then all b9 getParent() calls can be moved to getParentElement()
calls
> in b10.  I think getParent() has to continue returning a Parent just
to
> be sensible.
>
> Thoughts?
>
> -jh-
>
>
> Robertson, Jason wrote:
> > So, just wondering, why doesn't Parent have a getParent() method?
> >
> > It seems like this would be reasonable given XML's hierarchical
layout, i.e.
> > if you have a parent it's only one parent so getParent() would be
> > unambiguous. Comparatively it doesn't make sense for Child to have
something
> > like getChild() since going down the tree is much more complex.
> >
> > In this one tool I've written I have quite a few places where I do,
for
> > example
> >
> > getParent().getParent().getParent().getAttribute()
> >
> > and of course I could replace it with XPath, or this:
> >
> > ((Element) ((Child) ((Child)
> > getParent()).getParent()).getParent()).getAttribute()
> >
> > but this looks kinda funny and it just feels like you should be
able to
> > string getParent() calls together directly. I guess you'll still
have to
> > cast an Element in the end, but one cast is better than several.
> >
> > Jason
> >
> > p.s. I have approx 1 month of jdom-interest locally, and I searched
that but
> > didn't find anything. If this has been previously discussed let me
know and
> > I'll hit the archives.
> >
> > -----Original Message-----
> > From: Bradley S. Huffman [mailto:hip at a.cs.okstate.edu] 
> > Sent: Tuesday, May 27, 2003 4:47 PM
> > To: bob mcwhirter
> > Cc: jdom-interest at jdom.org 
> > Subject: Re: [jdom-interest] (no subject)
> >
> >
> > At one time I think I had a patch to jaxen that took care of this.
I'll
> > look for it when I get home, make sure it still works, and send it
in for
> > jdom-contrib.
> >
> > Brad
> >
> > bob mcwhirter writes:
> >
> >
> >>Yah, fwiw, this broke jaxen and jxpath and their support of JDOM,
> >>according to gump.  I haven't gotten jaxen fixed yet.
> >>
> >>	-bob
> >>
> >>
> >>On Tue, 27 May 2003, Jason Hunter wrote:
> >>
> >>
> >>>>elementMatched(String path, Element e) {
> >>>>  String parentName =
> >
> > e.getParent().getParent().getAttributeValue("name")
> >
> >>;
> >>
> >>>>}
> >>>>
> >>>>This no longer works because getParent() returns a Parent instead
of
> >
> > an
> >
> >>>>Element. Is there a way around this?
> >>>
> >>>Cast it?
> >>>
> >>>-jh-
> >>>
> >>>
> >>>_______________________________________________
> >>>To control your jdom-interest membership:
> >>>
> >
> >
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourho

> >
> >>st.com
> >>
> >>--
> >>Bob McWhirter        bob at werken.com 
> >>The Werken Company   http://werken.com/ 
> >>
> >>_______________________________________________
> >>To control your jdom-interest membership:
> >>
> >
> >
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos

> > t
> >
> >>.com
> >
> > _______________________________________________
> > To control your jdom-interest membership:
> >
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos

> > t.com
> > _______________________________________________
> > To control your jdom-interest membership:
> >
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

> >
>
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

>
>

_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com