 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Struts - A MVC web framework | | Tomcat - JSP/Servlet container | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | | JSP - A mailing list about Java Server Pages specification and reference | |
Struts & Hibernate
|
|
|
| | | SV: [jdom-interest] Announcing JDOM b10-rc1 | SV: [jdom-interest] Announcing JDOM b10-rc1 2004-02-14 - By Per Norrman
Back
Hi,
som feedback (late in the game ...)
I have seen the Parent/Child stuff in CVS but never actually looked at
the changes and consequences in detail. Until now.
To me, the Parent/Child/Container/Content/whatever stuff is really of no
practical use. Over the years (four, isn't it?) I've acquired a certain
JDOM
coding style, which is now suddenly subliminally altered. There was once
a vision,
an interface-less vision, which is now blurred. Funny thing, when I
study my
collective JDOM code, I never seem to treat a Document node the same as
an
Element node! In fact 99.99% (or close) of my processing is concerned
with either an
Element, an Attribute or a Text node. I think there isn't enough
commonality
to justify a Parent abstraction, at least not in the practical cases.
I really think these changes are going to make more harm than good,
considering
the (long) history of the API.
As an experiment, I took the beta-10 code and applied it to an older
project, started
with beta-7 and where beta-9 worked OK. This code does some really
intricate navigation inside a rather large, validated, document.
Element#getParent() not being an Element
really blowed that piece of code away!!
As for the method names, getChildren/getChildElements, etc: this issue
is of minor
importance, considering the modern IDEs (as long as the behaviour is
the same).
For the record, I would prefer getChildElements (or even
childElements--the JavaBeans
naming standard is overused).
I think this is my point: Stick with the initial vision, follow through
with the
consequences. You are never going to achieve the perfect API**. Skip
Parent/Child!
Two other issues, perhaps on a smaller scale:
*) Did you consider the change I proposed to XMLOutputter?
http://www.servlets.com/archive/servlet/ReadMsg?msgIdD7565&listName=jd
om-interest
*) Why can't I *get* the current Format from XMLOutputter?
**
Or maybe this is the "Quest for the Holy API". We are are all going to
be arrested
on a Scottish moor for believing in an ephemeral computational vision,
thus being a
threat to the IT society as a virtual impossibility ....
/pmn
> -- --Ursprungligt meddelande-- --
> Fr?n: jdom-interest-admin@(protected)
> [mailto:jdom-interest-admin@(protected)] F?r Jason Hunter
> Skickat: den 6 februari 2004 10:09
> Till: jdom-interest@(protected)
> ?mne: [jdom-interest] Announcing JDOM b10-rc1
>
>
> Good news!
>
> After today's work I'm proud to report there are NO known API changes
> required before our 1.0 release. What we have now is my best effort
> at a 1.0 release API.
>
> We may still have bugs or inconsistencies, but the TODO is wiped clean
> of everything I personally deem important enough to stand in
> the way of
> a long, long, long awaited 1.0 release.
>
> My goal is to get us to a 1.0 release in the next 6 weeks. Here's my
> plan.
>
> I've posted on jdom.org a Beta10 Release Candidate #1. It's built
> from the very latest CVS source. You can get it at
> http://jdom.org/dist/source/jdom-b10-rc1.zip.
>
> I'd like people who are using b9 to download this and see how things
> work. Please double check everything's still prim and proper and
> performant. The code passes all the jdom-test cases, but they don't
> have great coverage (although they did help me find a bug earlier
> tonight). Subclassers: I'm especially interested in hearing your
> feedback since we restricted a lot of visibilities.
>
> Then I'd like people who've been involved in the API design to
> thoroughly scour the new Javadocs (online also at
> http://jdom.org/docs/apidocs/). Do all the new structures make sense?
> Is everything consistent?
>
> Once we're satisfied this b10-rc1 code and interface is correct (in
> perhaps one to two weeks), we'll ship the formal Beta10. After that,
> we'll get started on the 1.0 Release Candidates. The first 1.0-rc1
> will be Beta10 minus the deprecated methods. (We need to ship 1.0
> without any deprecations.) We'll try to spread the word to everyone
> that 1.0 is
> coming and make sure people test their code against it. We'll have a
> month to iron out any issues.
>
> Throughout this process, API corrections will be more important than
> code corrections. I'm happy to ship a 1.0.1 with code fixes, but I
> want the 1.0 API as solid as possible. We've done a bunch of
> changes since
> b9, so there's a lot to review.
>
> Sound good? When we ship 1.0, I'll collect all those beers. :-)
>
> -jh-
>
> __ ____ ____ ____ ____ ____ ____ ____ ____ ____
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr@(protected)
__ ____ ____ ____ ____ ____ ____ ____ ____ ____
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@(protected)
.com
Earn $52 per hosting referral at Lunarpages.
|
|
|
