+1 on JDOM unless you know upfront that the XML file is going to be big (greater than a couple of MB).
--- sudip shrestha <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
