Joe Germuska wrote:
At 8:42 AM -0500 1/14/05, Erik Weber wrote:
If you are not familiar with a lot of XML-related APIs, the easiest approach is to use the SAX API, in my opinion*.
You may be the first person I've ever encountered who finds SAX the easiest way to process XML!
Heh. I guess it's because I've written so many SAX event handlers, I feel like I can do it in my sleep now. I probably wrote a few (surely inferior) versions of commons-digester in my time. :) In fact, when I first started doing Web-app programming, I wrote an entire Struts-like framework complete with XML-based validation, similar to commons validator (I knew what Struts was but didn't feel like learning it at the time), as well as app configuration. I started with DOM but ended up using SAX for all that as I recall. Lately I've been using pull parsers, which are more efficient, but I still think not as dumb as SAX (dumb == good -- I like typing. Makes you feel like you're accomplishing something. Thinking hurts my noggin. :D ). Also, while I see your point that the overall concept of DOM might be more sensible in theory than that of SAX, I found that it's just easier to get going with the SAX API than with DOM or even JDOM. You can get something working with very few lines of code, and good examples are all over the Web. SAX can be a pain to debug though.
I read this awesome book called "Building Parsers in Java" a couple years ago (best ASCII-art cover ever) that really inspired me and got me thinking along the right lines for using a model like SAX. It's kind of like, you have this robot, and you keep handing him parts. The robot is smart enough to know which parts to keep and which to ignore (pull is definitely a smarter model than this -- the robot would ask for the parts he wants -- but this is simpler). He keeps a collection of "running" objects -- objects that he has started assembling but hasn't yet finished. Managing the running objects is the only part that really involves any thought in coding. Assembly of an object normally starts when an opening element tag is encountered. Assembly continues as sub-elements and attributes are discovered. Once he has finished the object (usually when a matching closing element tag is encountered) the robot adds it to the final Collection, Map or complex Object to be returned. To me, it's kinda elegant. But the "deeper" the XML, the more difficult it becomes, because there are more running objects at any given time.
But I appreciate your elaborating on commons digester. That's the one I was thinking of. I'll have to check that out. Also, I've never even looked at Spring. By the way, do you happen to know what type of parser either of those uses? Just curious.
Thanks, Erik
* There are higher level APIs that might suit you better, depending on what you are doing. Struts and Commons Validator use some sort of higher-level "config" library, if I'm not mistaken, that is designed for constructing objects/Maps out of config files, so you might have a look at the source code for one or both of those. I'm sure someone else could on the list could better inform you about this.
This is commons-digester, and it does in fact make it extremely simple to read XML and produce objects from it, especially if you have the liberty of defining the XML syntax before you write the processing code. Digester really helped me get my design oriented towards decent externalization of configuration elements. I now prefer the Spring Framework's bean factory, because it standardizes what I normally use Digester for without needing to write even XML processing rules.
Since I started using Digester (and then Spring), I have not had much cause to deal with XML in the DOM form directly, although I would think that for most newcomers, the tree model is more straightforward than SAX's event model. If you do need to do something with DOM, it's probably worth checking out dom4j or JDOM, two apis that simplify the DOM and provide a more Java-like API.
Joe
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
