Data validation is particularly important when dealing with web development. Especially when passing user input to the database it should be checked not only for validity but also for malicious content.
Something that really bothers me recently (don't ask, project at work) is the level at which the validation is often done when using servlets. Mainly, in the servlet itself. I don't like that. It adds a layer of complexity that is really unecessary and makes reuse and architecture of code more difficult than it has to be.
Java is an object oriented language.. why not use that aspect of it to its fullest ability? Mainly: an object ought to validate itself. So, if you have a user object, instead of using servlet code to validate its attributes (for instance: email address) make the object know what the valid value is.. and return that to the servlet. "Hey object, are you valid? Sure thing! Okie dokie!" .. or.. "Hell no, here's your problem, make them fix it".
Easier, no? Seems obvious.. but apparently not to everyone.
TrackBack URL for this entry: http://www.unix-girl.com/mt/mt-tb.cgi/594
That's why IllegalArgumentExceptions and setters are for. But why so few people use them, that's beyond my knowledge.
#After seeing the WebWork way of doing property validation, I really like the java.beans approach. You can create Editor classes for each "type" of data, assign an Editor to a property via a BeanInfo class. That way your POJO's aren't carrying around a bunch of validation code that you might want the option of switching off...but you can still access the validation in a nice magical way using Introspector. Check out WW's property validation feature for more on that idea.
#We used classes with validating methods (public static) and for our objects constructors with a String argument using these methods in turn.
The hard part with IllegalArgumentsExceptions is to wrap every validation with a try-catch block in order to be able to present more than one validation error to the user at a time.
My solution was to have methods like
validate(String enteredValue, String fieldName, Map errorList), where an error list is filled with key-value pairs (key= field name in the form, value=error message).
Just my 0.02 €
#absolutely. i saw frameworks put validation in views or configuration xml, can't understand why. besides, too much stupid typing in anti-java syntax for even the simpliest validation rule. example:
<faces:textentry_input id="zip" modelReference="${CustomerBean.zip}" size="5">
<faces:validator className="javax.faces.validator.LongRangeValidator"/>
<faces:attribute name="javax.faces.validator.LongRangeValidator.MINIMUM" value="10000"/>
<faces:attribute name="javax.faces.validator.LongRangeValidator.MAXIMUM" value="99999"/>
</faces:textentry_input>
give me a break...
I'm thinking about using 'design by contract' or xdoclet whatever, so that above crxps would be just
/** @post zip>10000 && zip<99999 */
public void setZip(....
But then you run into problems when you want different validtors for different usages of the same class. In Webwork, for instance, you can have multiple aliases for a single class, and you might want different validation based on the alias. This becomes ugly in code, but is easily handled in external configuration files.
#1st up not a Java proggie, C [the one and only - sorry no holly wars :)]
Agree with your concept; validate within and return error condition(s). You should validate that what has been passed in is correct (as you see it) for your function/class/et al.
Originally you wrote it for you and of course it would never (sic) get called with crap. Then someone sees it and likes its functionality but misses the small print [you did comment didn't you ? :)] so ...........
Just my 2p's worth (32c at current exchange)
#i want to have more information about data validation.
#