Recommended: Sing it, brah! 5 fabulous songs for developers
JW's Top 5
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Read the whole "Validation with Java and XML Schema" series:
This series of articles, and the code included, seeks to at least limit, if not completely stop, the drool and boredom, the hours spent looking out a window (or a cubicle wall!) wishing that you were outside playing hockey or listening to the Dave Matthews Band in concert. I'm thrilled at the response so far, and am glad you've come along for the ride. Before diving into this final article in the series, let me give the newcomers a little history.
Well, I'm happy to see you've made it this far. As an author, there is a certain wariness about moving beyond a series that has more than three parts. It's the "trilogy" fear, I suppose; other than Star Wars, there aren't many trilogies that have successful fourth outings. I mean, did any of you really anxiously await Friday the 13th, Part IV? In any case, I am glad that you are still reading.
In Part 1, I talked at a conceptual level about problems common to applications with user input and raised the issue of validation.
I discussed using Java properties files as well as hard-coded solutions and the various shortcomings of those approaches.
Finally, I suggested that XML Schema might provide a means to represent data constraints easily and completely and previewed
the framework that is the focus of this series. In Part 2, I demonstrated how you could use some simple Java classes to represent data constraints defined in an XML Schema. This laid
the groundwork for building a set of these Constraint instances and then comparing Java data (Strings, ints, Dates, etc.) to these data constraints. In Part 3, I rounded out the framework, providing the SchemaParser class to parse the XML Schema and build up these constraints. And finally, I showed you the Validator class, which would take data and a constraint name and return whether or not the data was valid with regard to the supplied
named constraint. For those of you who haven't read these parts, I strongly recommend that you read the first trilogy of articles
before moving on.
So far, we have a pretty good set of classes to help us out in validating data in applications, and particularly in servlets. But there are some things missing in the framework; while validity of data is determined, there is no means to report what problems occur when data is invalid. This will be the focus of this article. Additionally, I've yet to "put it all together" and give you a solid concrete example. I'll also do that in this article and hopefully let you better see validation in action.