[jdom-interest] A utility Element subclass and a request for API extension

[Jason Hunter]

Comments from the list?  The good part about an open source project is
we can see what people think?  I'm easy either way.

My one concern is do these methods go on Element (setAttribute),
Attribute (setValue), or both?

-jh-

Les Hill wrote:
> 
> jhunter at servlets.com writes:
> > Have you thought about just using the ""+ trick?
> 
> Actually, yes.  Using "" + is better than:
> 
> setAttribute("myFloat", Float.toString(someFloat));
> 
> But suffers from the same problem in the long run.  Doing it once or twice
> or ten times is OK, scattering it everywhere begs for a cleaner solution.
> 
> > It's not too bad, and probably nicer than making Element larger.  One
> > goal of JDOM is simplicity.
> 
> Not to beat a dead horse, but simplicity does not imply minimalism.
> 
> I would argue that extending the API to include utility methods providing
> *exactly* the same intention+ with similar but not the same signatures, does
> not introduce complexity and promotes use.
> 
> As an example of how this kind of utility method is useful, I recently
> switched over to 1.4 and started using the 1.4 logging instead of log4j.
> Both have the generic log method (signatures not exactly correct for
> clarity):
> 
> log.log(Level level, String msg)
> 
> which writes the message to the log at the specified level.  Both also have
> utility methods of the form:
> 
> log.warning(String msg)
> 
> which writes the msg to the log at a warning level.  However, when it comes
> to exceptions, the log system in 1.4 only provides the generic method:
> 
> log.log(Level level, String msg, Throwable thrown)
> 
> while log4j provides the generic and the various utility methods:
> 
> log.warning(String msg, Throwable thrown)
> 
> No difference in functionality: in either case the message is written with a
> stack trace at the given level.  Amazing difference in daily ease of use.
> 
> I offer this as a suggestion as a user of JDOM who is not trying to
> manipulate XML documents per se, but rather as a user who is using XML as an
> adjunct to everyday applications where attributes are regularly a native
> Java type instead of String.
> 
> + In this case setting the value of an attribute -- this would be opposed to
> overridden signatures that change intended behaviors.
> 
> Regards,
> 
> Les Hill
> leh at galaxynine.com