JDOM: http://www.jdom.org/. If you are new to xml-java parsing, then this is the way to go. When I started learning about xml parsing with java a while ago, I researched various methods and found that JDOM provides the easiest route to get things done. A quote from JDOM mission: "It behaves like Java, it uses Java collections, it is completely natural API for current Java developers, and it provides a low-cost entry point for using XML".
On Fri, 14 Jan 2005 10:34:58 -0500, Erik Weber <[EMAIL PROTECTED]> wrote: > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
