Re: [OT] Re: Using XML in struts
Thanks. Hope you like them. Nice looking site by the way. Erik Vic wrote: You do need a life. But... I just bought 2 books from your list. I keep a track of cool design ideas here: http://sandrasf.com/kiss - so if anyone wants to append there they can. (I like SQL Tuning, SQL for smartites and Doug Lea's book on concurency.) .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [OT] Re: Using XML in struts
Kindly send all your messages to [EMAIL PROTECTED] This mail account is not functioning anymore. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: Using XML in struts
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! * 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 -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Using XML in struts
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]
Re: [OT] Re: Using XML in struts
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. Certainly not more sensible -- in fact, I've seen over and over again people who aren't comfortable with SAX implement things that involve reading enormous amounts of XML using DOM and then running out of memory. But they decompose the problem into first, get everything in; then do something to everything instead of get one in, handle it, and discard it. I read this awesome book called Building Parsers in Java a couple years ago That sounds worth looking up... 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. Digester is a wrapper around SAX. Digester itself extends org.xml.sax.helpers.DefaultHandler And while the most common way people use Digester is to create a tree of objects, once you get inside it, you realize that you can do a lot more. You can write Digester rules that do the aforementioned get one, handle it and discard it as well as the more common rules which do get one and add it to the tree. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Using XML in struts
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]
Re: [OT] Re: Using XML in struts
+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 -
Re: [OT] Re: Using XML in struts
Joe Germuska wrote: 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. Certainly not more sensible -- in fact, I've seen over and over again people who aren't comfortable with SAX implement things that involve reading enormous amounts of XML using DOM and then running out of memory. But they decompose the problem into first, get everything in; then do something to everything instead of get one in, handle it, and discard it. I was trying to agree with you. :) But yeah, you're right of course. I read this awesome book called Building Parsers in Java a couple years ago That sounds worth looking up... These days, so many books are about how to use vendor products or APIs. Mastering this or that, Up to Speed with this or that, and the ever popular Professional this or that. I'm not knocking those -- I need those too of course. But I really appreciate getting my hands on those rare books that just focus on the fruits of someone's creativity and inventiveness. You may never need to create your own language or even build your own regular expression parser, but, do you enjoy the art of programming? Do you enjoy math and science? Do you like to learn about different ways to approach the same problem? Do you like to build a better mousetrap? Dragging and dropping beans and jar files is not my idea of a good time. Too bad all any client/tech shop seems to want is the same thing someone else already has done, with a new marketing twist. Once we have CRUD in a bottle for $19.95 and all the legacy stuff is snuffed out, what will programmers do for a living? Ah, I'm just complaining as usual. Anyway, of the dozens of Java books I have discovered and/or bought in the last few years, a few stand out in the way I described: * Building Parsers With Java, by Steven John Metsker, Addison Wesley (0-201-71962-2) -- creative, well organized, well written, well edited, just a nice piece of work that definitely wasn't cranked out. A fun book about creating and interpreting your own languages. * Digital Audio with Java, by Craig A. Lindley, Prentice Hall (0-13-087676-3) -- ever wanted to know how to build a parametric EQ in Java, from the knobs and LEDs all the way to the wave shaping? * Java Design, by Peter Coad (TogetherSoft) and Mark Mayfield, Prentice Hall (0-13-981-6) -- offers a perspective on design that you probably won't find anywhere else (with chaper titles such as Design with Threads and Design with Notification, and hand-drawn diagrams); forget that IDE and get out your pad and pencil. Perhaps funny that I should say this, being a lover of lowest-level programming, but I have found that the books that have helped me the most as a programmer (in the long run) are ones about design patterns, idioms and algorithms (all high-level things in some fashion), rather than those about the latest API or product. Unfortunately I cannot back up that statement with $$$ earned -- at least not yet. The GoF book was published how long ago? How many tech books of today are of equal value? I guess it depends on your perspective. Speaking of perspective, ever read The Timeless Way of Building? How about (wyy OT) The Fourth Dimension? Man, I need a life. :) Cheers, Erik 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. Digester is a wrapper around SAX. Digester itself extends org.xml.sax.helpers.DefaultHandler And while the most common way people use Digester is to create a tree of objects, once you get inside it, you realize that you can do a lot more. You can write Digester rules that do the aforementioned get one, handle it and discard it as well as the more common rules which do get one and add it to the tree. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Using XML in struts
You do need a life. But... I just bought 2 books from your list. I keep a track of cool design ideas here: http://sandrasf.com/kiss - so if anyone wants to append there they can. (I like SQL Tuning, SQL for smartites and Doug Lea's book on concurency.) .V Erik Weber wrote: Joe Germuska wrote: 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. Certainly not more sensible -- in fact, I've seen over and over again people who aren't comfortable with SAX implement things that involve reading enormous amounts of XML using DOM and then running out of memory. But they decompose the problem into first, get everything in; then do something to everything instead of get one in, handle it, and discard it. I was trying to agree with you. :) But yeah, you're right of course. I read this awesome book called Building Parsers in Java a couple years ago That sounds worth looking up... These days, so many books are about how to use vendor products or APIs. Mastering this or that, Up to Speed with this or that, and the ever popular Professional this or that. I'm not knocking those -- I need those too of course. But I really appreciate getting my hands on those rare books that just focus on the fruits of someone's creativity and inventiveness. You may never need to create your own language or even build your own regular expression parser, but, do you enjoy the art of programming? Do you enjoy math and science? Do you like to learn about different ways to approach the same problem? Do you like to build a better mousetrap? Dragging and dropping beans and jar files is not my idea of a good time. Too bad all any client/tech shop seems to want is the same thing someone else already has done, with a new marketing twist. Once we have CRUD in a bottle for $19.95 and all the legacy stuff is snuffed out, what will programmers do for a living? Ah, I'm just complaining as usual. Anyway, of the dozens of Java books I have discovered and/or bought in the last few years, a few stand out in the way I described: * Building Parsers With Java, by Steven John Metsker, Addison Wesley (0-201-71962-2) -- creative, well organized, well written, well edited, just a nice piece of work that definitely wasn't cranked out. A fun book about creating and interpreting your own languages. * Digital Audio with Java, by Craig A. Lindley, Prentice Hall (0-13-087676-3) -- ever wanted to know how to build a parametric EQ in Java, from the knobs and LEDs all the way to the wave shaping? * Java Design, by Peter Coad (TogetherSoft) and Mark Mayfield, Prentice Hall (0-13-981-6) -- offers a perspective on design that you probably won't find anywhere else (with chaper titles such as Design with Threads and Design with Notification, and hand-drawn diagrams); forget that IDE and get out your pad and pencil. Perhaps funny that I should say this, being a lover of lowest-level programming, but I have found that the books that have helped me the most as a programmer (in the long run) are ones about design patterns, idioms and algorithms (all high-level things in some fashion), rather than those about the latest API or product. Unfortunately I cannot back up that statement with $$$ earned -- at least not yet. The GoF book was published how long ago? How many tech books of today are of equal value? I guess it depends on your perspective. Speaking of perspective, ever read The Timeless Way of Building? How about (wyy OT) The Fourth Dimension? Man, I need a life. :) Cheers, Erik 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. Digester is a wrapper around SAX. Digester itself extends org.xml.sax.helpers.DefaultHandler And while the most common way people use Digester is to create a tree of objects, once you get inside it, you realize that you can do a lot more. You can write Digester rules that do the aforementioned get one, handle it and discard it as well as the more common rules which do get one and add it to the tree. Joe -- RiA-SoA w/JDNC http://www.SandraSF.com forums - help develop a community My blog http://www.sandrasf.com/adminBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
