I'm quite interested in the concept of software components and how those ideas can be applied to Java code. Thoughts or ideas I have on this subject get dropped here for the benefit of humanity and my own hubris.
Except where otherwise noted, all original content is licensed under a
Creative Commons License.
See details.
One of my personal complaints about my description of components is that I didn’t give any examples … and I have a special penchant for examples … and general malaise and buggery as well.
The other day found me needing to parse an XML file … something that I hate to do generally. DOM is just plain horrific and there is nothing simple about SAX. I like JDom a lot, as it is much more straight-forward.
But this day found me thinking it would be a good idea to discover XPath.
I’ve read up on, and even used it query expressions in dealing with transformations in XSLT (and if you were only to read some of the fine tutorials on the subject, you’d think it was pretty nice), but I hadn’t tried to do anything with the XPath API. But I found a shovel, and dug in and found it wasn’t too bad. Like most APIs, you just have to know the sequence of commands that you want use for what you typically use it for.
Enough background … it didn’t take me long to realize that I would soon forget this the next time I wanted to use this library … so I did what anyone should do in this situation … I created a component.
I figured that my “component wrapper” would have two properties … a reference to an XML file to parse, and an XPath expression. It would then have a method that I could call to get the data value out of it. This sort of thing will work perfectly for things like getting information out of a configuration file and whatnot.
Since I’m an extreme programmer, I defined the interface first, and then the test suite … and then I started to code the implementation. Now I can rest and not worry about my mind’s natural entropy … I don’t have to remember the XPath API … I can just instantiate this component.
And the nice thing about a component, is loading it up in your favorite “component assembler” tool, is that it could be quite obvious how to use it. Don’t worry, I also included documentation and instructions.
So … feel free to use my little Java Bean component. Everything you need is available in xmlbeans.zip. If you are using AppComposer, then just extract this zip file AppComposer’s directory, and you’re set. If you’re using another tool, place the contents of the “beans” directory (the jar) in the directory where your beans go. I even included, along with the JUnit test, a couple of test capsules in the examples/XmlQuery directory.
Note: My getValue method returns a String… that’s what I thought most useful. If you’re XPath query accessed an attribute of a node, then you’ll get the value of that attribute … seems right. But if your query accessed a node, then what? Well, I figured if that node contained a single text child, then that is what it should return. If it doesn’t, then it just returns the name of the node … not that useful in that case.
If you feel that you need the Node object, then there are a couple of methods that I added to get that stuff … but while they work (I’ve got a unit test to prove it), I haven’t used it for myself.
© 2003-2005, Howard Abrams • Except where otherwise noted, all original content is licensed under a Creative Commons License (see details).
I thought I might clarify a point …
The purpose of this “bean” is to convert a tag’s value embedded in an XML file into a string. Sometimes, what a tag’s value “means” is clear, e.g. If you specify an attribute of a tag, then the value would be the data associated with that attribute. For example, given an XML frag:
The query, //message/@title would return, Hello World … Yes, obvious indeed, even if the XPath expression is foreign.
However, what if the query referred to a tag containing a tree of children? What does the “string value” mean in this case? These non-obvious cases are generally described as an error (as the user should make a better query expression), but I think that it would be more helpful to return something… So, I’ve taken liberties to return “something” if the default would be “null”.
For instance, consider the following XML fragment:
This is just some HTML-formatted text.
The query, //message (or just “message”), would first get the “message” tag, and realize that it has one attribute and three children (keep in mind the <b> tag is a real XML tag as well).
What we do in this case is return the “guts” of the tag. In this case, we would return:
This is just some HTML-formatted text.
And typically, this is what you want. Especially, if the contents of a tag could contain some embedded XML tags, we should retain the tags, as they may be useful later on. In my use of it, I often store messages (with HTML formatting) in my XML files, and these messages are often sent to a remote browser as is…
Comment posted on Friday, 22 August 2003I guess this would be version 1.1 of this component that I just released. Most notable feature is the fact that I changed the name to XmlQuery.
The second major feature is the addition of some new examples that run within AppComposer. Once you’ve installed this component, just open the examples/XmlQuery/ACProject.zap file and you’re set.
Comment posted on Monday, 25 August 2003
|
|
|
|
|
|