[jdom-interest] Helper methods [eg]

[philip.nelson at omniresources.com]

Elliotte, I think you missed the same thing I did on my first read.  He is
not suggesting that these helpers should go in the core.  As you have
suggested many times before, Alex is looking at starting an org.jdom.helpers
or org.jdom.util.  I think it's a good idea and if my memory serves correct,
so do you :-)

Actually, my first thought is to use the jdom-contrib mechanism to get this
started.  Once there with enough support, we can decide which things are
distributed in the helper/util package at a later time.

Here are some other things I think could go there (off the top o' my head):

- TreeWalker with a visitor or command type extension feature
- decorators for Element, Attribute and Document (I can generate a base
decorator)
- proof of concept subclass project as a demonstration of the subclass
implementation. (a listener enabled version would interest lots of people).

I am also very interested in finding out if there is anything in JDOM that
would be incompatible or inconvienient with digital signatures.  It seems to
me that Web Services will bring xml into the mainstream programming world,
hitting that HUGE number of microsoft oriented programmers.  This won't
happen overnight, but it appears that this could be a killer use of JDOM, a
more data oriented api on xml.  Web services will almost certainly use
digital signatures at some point.  A proof of concept project for this seems
to be a really good idea.





> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo at metalab.unc.edu]
> Sent: Thursday, April 19, 2001 8:04 AM
> To: jdom-interest at jdom.org
> Subject: Re: [jdom-interest] Helper methods [eg]
> 
> 
> At 9:28 PM -0400 4/18/01, Rosen, Alex wrote:
> >I would like to bring up the topic of adding helper methods 
> to JDOM, so
> >mulitiple users don't have to write common routines 
> themselves. I envision
> >these as static methods on one or more classes in a packaged named
> >org.jdom.helpers or org.jdom.util. Some possible examples include:
> >
> 
> I REALLY don't like this idea. As somebody who spends a lot of time 
> documenting APIs, I tend to think that helper methods just muddy the 
> water and confuse things, especially when they're in the same 
> packages as the core. In general. I think that APIs should be as 
> simple as reasonably possible. Helper methods should be added only 
> when they're something that 90% of use cases are going to need and/or 
> they save a lot of work when they are used. I don't think these meet 
> either criterion. If you really want these, they're easy enough to 
> add in a subclass in jdom-contrib without cluttering the core API.
> 
> >- Getters which would throw exceptions if the requested data 
> is not available:
> >getRequiredAttribute(), getRequiredChild()...
> >
> 
> We already had this argument. Exceptions lost. I certainly don't want 
> to provide one set of methods that returns null and another that 
> throws the exceptions. That way lies confusion.
> 
> >- Getters and setters for datatypes, e.g. getIntAttributeValue(),
> >setIntAttributeValue(), getIntText(), setIntText(), 
> getIntChildText()...
> >
> 
> Unnecessary clutter. And where does it stop? setFloatText()? 
> setDoubleText()? setBigDecimalText()? setInputStreamText()? 
> setKitchenSinkText()?
> 
> >- Modification methods which preserve formatting - an 
> addChild() method which
> >would add necessary indentation so the XML continued to look 
> nice, and
> >removeChild() which removed the remaining whitespace so 
> there wasn't a big
> >empty hole in the document.
> >
> 
> No, trying to pretty print XML at this stage is actually modifying 
> the logical structure of the document and is not infoset compatible. 
> This option can be left for an outputter.
> 
> 
> >- findChild(), which could find the child element with a 
> specific attribute
> >value, for example.
> >
> 
> XSLT/XPath on 1.1 is how this will be done.
> -- 
> 
> +-----------------------+------------------------+-------------------+
> | Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
> +-----------------------+------------------------+-------------------+
> |                  The XML Bible (IDG Books, 1999)                   |
> |              http://metalab.unc.edu/xml/books/bible/               |
> |   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
> +----------------------------------+---------------------------------+
> |  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
> |  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
> +----------------------------------+---------------------------------+
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr at yourhost.com