Re: Why digester?
Impresive explanation Craig, :-o Many thanks, Adolfo From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: Why digester? Date: Sat, 22 Jun 2002 12:17:32 -0700 (PDT) On Sat, 22 Jun 2002, Adolfo Miguelez wrote: Date: Sat, 22 Jun 2002 14:38:07 + From: Adolfo Miguelez [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 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. 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, Adolfo _ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Why digester?
AFAIK, Digester uses Xerxes 1.3+. Mark -Original Message- From: Adolfo Miguelez [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 22, 2002 10:38 AM 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 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. 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, Adolfo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: Why digester?
Hi Adolfo. I think the digester is no contradiction to a xml-parser. The digester uses a xml-parser and will make the parsing more comfortable. So you only must deal with java classes and not with xml-tags. For my opinion it is a little bit oversized, but thats a matter of taste - we say in germany ;-). You may use a parser of your choise e.g. xerces, dom4j to parse your own documents. Myself I use configurable (http://sourceforge.net/projects/configure/), a litte framework that I have written to configure my things in struts. The goal is the same: I will not have xml-parse-code in my application, I will use a framework, that does parsing for me. Manfred -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Im Auftrag von Adolfo Miguelez Gesendet: Samstag, 22. Juni 2002 16:38 An: [EMAIL PROTECTED] Betreff: 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 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. 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, Adolfo _ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Why digester?
On Sat, 22 Jun 2002, Adolfo Miguelez wrote: Date: Sat, 22 Jun 2002 14:38:07 + From: Adolfo Miguelez [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
