struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Why digester?
Date Sat, 22 Jun 2002 19:17:32 GMT


On Sat, 22 Jun 2002, Adolfo Miguelez wrote:

> Date: Sat, 22 Jun 2002 14:38:07 +0000
> From: Adolfo Miguelez <pelly69@hotmail.com>
> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> Subject: Why digester?
>
> Hi All,
>
> a strange question this time. I just wonder why Struts (and other Jakarta
> products, as Commons bunch, etc) is based in the digester parser rather than
> JAXP, JDOM, or another one.
>

I think you're getting some concepts mixed up.  Digester is not itself a
parser -- it is an easier-to-use wrapper around the SAX APIs that use a
SaxParser acquired via JAXP APIs.  It can operate on any parser that
supports JAXP, as long as you meet the version dependencies (Struts 1.0
depends on JAXP 1.0, while Struts 1.1 requires JAXP 1.1).

> I guess, that Jakarta guys have developed a parser from scrath, in order to
> customize it for their necesities. However, I also guess that it does not
> match the Java/Sun specs. So my own response is having a parser that they
> consider confidable and that they could configure to match they requisites.
>

Digester depends on acquiring an XML parser via JAXP.  It is not a parser
itself.

> The question arises when, thinking in extend Struts, with some ocasional
> code that could parse a XML file, I wonder what advantages give me to use
> the digester? Why Jakarta guys implemented and use it?
>
> Any light to clarify this design question would be appreciated. Thanks in
> advance,
>

The original approach Digester is based on was the way that Tomcat 3.0
(yes, that long ago) parsed web.xml and server.xml files.  Configuration
file reading is typically a one-pass operation, with no need to maintain
the entire document in memory for random access (the way that DOM parsers
to it).  In other words, it's a perfect situation to use SAX-based
parsing.

However, writing SAX-based parsing code is really mind-bending, because
you have to think in terms of very low level events (it reminds me of why
I don't enjoy writing Swing-based GUI apps :-).  Therefore, Digester was
written to simplify the task of converting an XML-based configuration file
into a tree of Java objects that (generally) has internal relationships
matching the nesting of the XML tags.  Digester provides a nice pattern
matcher that lets you, for example, say "whenever you see an <action>
element nested inside an <action-mappings> element, do the following
things" using an object called a Rule.  A bunch of useful Rule
implementations are included, and you can also create your own.

Think of Digester as a higher level abstraction around SAX, optimized for
converting XML documents into corresponding object trees (reading
configuration files is a common example of this use case), that hides all
of the nitty gritty details.  It's so good at this role that many projects
are adopting it for parsing config files, including Tomcat 4.1 which uses
commons-digester just like Struts 1.1 does.

By the way, if you need to go the other direction (Java objects --> XML),
there's an interesting project called betwixt in jakarta-commons that
plays very nicely with Digester.

> Adolfo
>

Craig


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message