commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [Digester] The purpose of digester
Date Thu, 13 Feb 2003 17:34:24 GMT


On Thu, 13 Feb 2003, Erik Price wrote:

> Date: Thu, 13 Feb 2003 11:56:54 -0500
> From: Erik Price <eprice@ptc.com>
> Reply-To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
> To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
> Subject: [Digester] The purpose of digester
>
> Does Digester have a dedicated "purpose", or is it intended to be a
> flexible high-level API for accessing XML data (for any purpose)?
>

The original motivation for the code in Digester was to read configuration
files with relatively complex internal structure -- most particularly,
things like web.xml and server.xml in Tomcat.  The Digester code itself
was factored out of Struts because it turned out to be generally useful
for many XML --> Object conversions.

One way to think about Digester is a higher level abstraction over SAX
parsing (which is what it does under the covers).  It's especially nice
for applications where you just want to pull a few relevant things out of
a structure, or you want to take advantage of things like the
SetPropertiesRule, which automatically maps XML attributes into calls to
the setter methods of a JavaBean.

> I'm developing an app that will need to store certain information.  I'm
> considering using XML just to learn more about some of the issues
> involved in using XML for this purpose.  Digester is an attractive means
> of parsing those files.
>

Yep.  You might also want to look at Betwixst if you have to go the other
direction (Object --> XML).

> Also, is there a compelling reason to use XML instead of Property files?
>

One key word:  hierarchies.

If you're familiar with Tomcat, you've undoubtedly looked at server.xml
files that sometimes have nested structures five or six levels deep.  With
a properties file, you have to use huge long property names to distinguish
the fact that you're setting (say) the auto-reload property of web
application A instead of web application B.  With XML's nesting of
elements, the nested elements are naturally scoped to the elements they
are nested in, so you can use much shorter names.

If the data you are reading isn't really hierarchical (say, the properties
you would use to configure a JDBC connection), properties files work fine.
If you've got a huge structure with deep relationships, you'll really like
XML a lot better.

> Just curious!
>
> Thanks,
>
> Erik
>

Craig

Mime
View raw message