I cannot tell my servelet users that the data they entered was incorrect.

Question

HI, I am making a web application which includes a servlet, several java classes and html pages. One of the html pages is a form with all sorts of user inputs (textfields mostly). I know how to use java to determine if the data entered is the correct type that I need for the program (eg, cost needs to be a xx.xxx double, quantity and int between 1-99 ect). What I don't understand how to do is when the user hits submit is to make tell the user somewhere in the web browser (either on the same page or a new page) that their input was incorrect and not try to save it to the program. Then give the user a chance to fix the input and try it again. I don't have the slightest idea of how to start this, but I see web pages do it all the time. I think I'm just using the wrong vocabulary in my search. Could someone please give me an example or at least steer me in the right direction in my search? thanks.

Answer 1

njb7ty wrote:
I find this link useful:
http://www.xs4all.nl/~sbpoley/webmatters/formval.html
As a general rule, you do your client side validation in javascript, put error messages in red next to the textfield that has a problem, and dont let the user submit if there are any errors. When the page is submitted back to the servlet, you do the same validation again (to ensure the user didn't turn off javascirpt on their machine, or some hacker tried to get around your client side validation). You also do more through validation on the servlet that wasn't practical to include on the JSP. If server side fails, redisplay the page with the same text in red next to the offending textfield(s). If a more complex error occurs, put an error message in red at the top of the form explaining the problem. If all is ok, put ' **** successful update ****' in green at the top of the page to indicate all went well. If you redraw the page, dont forget to repopulate the page with any unsaved data the user may have previously entered.The general rule is "never trust the client". This applies to validation, security and a host of other concerns. You never know whether a given request actually came from one of your clients. You can do some fancy crypto to attack this problem, but it only kicks the can down the road. Always treat a client request as from an outside source, one that you do not control.
Any validations you perform on the client are really solely to enrich the user experience, whether that is by giving more immediate feedback (e.g., avoiding a server trip) or highlighting the error on the page or collecting a series of responses ala a wizard before submitting them, etc.
Now, in terms of performing the same validations in your Servlet, it is a maybe-yes and maybe-no answer. If you have a proper service tier and/or rich domain model, then the validations should be performed there and not in the Servlet. The latter, in this context, is a client like any other. (Imagine you have Struts 2 with a ton of validations, and then all of a sudden you want to add web service support, if the validations are in the VC tier, you are in trouble). If instead your Servlets simply talk directly to DAO's an do the actual business logic, then yes, you can place validations there.
The idea is that any validations must occur as close to the actual service or business logic that is invoked. You can put them in the VC if you like, but again, this is solely for user experience and should in no way ever impact your analysis of the security of or the validations applied to a given method.
- Saish