Please see the document at http://web.tiscali.it/javaextreme_net/jsp_pattern/jsp_en_rev3.htm

Sorce code can be downloaded at
http://web.tiscali.it/javaextreme_net/jsp_pattern/SourceCode.zip

All this stuff has not been published yet, hope to find your interrest. Let me know. Thanks.

Luigi.

The article is interesting, although I have to wonder if throwing an exception for validation errors is appropriate...at first glance I think it is not such a bad idea, but I still wonder...

You could also use a validation framework such as FormProc. FormProc provides pluggable validation, object population, i18n message handling, etc. It includes validation with regular expressions, Java classes, scripts, etc.

Sincerely,
Anthony Eden

>validation errors is appropriate
I was wondering about what could be a good use of JSP error pages in a web application. Lot of people just use a JSP error page to display the stacktrace when things goes wrong seriously, but I wanted to make something more useful, having a simpler code than wrinting huge blocks of

if (...some field is wrong...) {
  set the message to be displaied
  go back to the imput form
} else if (...another field is wrong...) {
  set another message
  go back to the imput form
}

I think that exception mechanism is a stepstone for error-handling in OO languages. But, ok, in this case you won't catch the exception or make a try/catch block :-) just display it.
I believe it could seem a strange approach, but I find it smart and easy.
 
I noticed a little conflict with Weblogic: it appends a piece of stacktrace to the exception message (I believe this should not be done by WebLogic), but with little touch to my code the problem can be fixed.

>at first glance I think it is not such a bad idea, but I still wonder...
Thanks very much, I would like to read more about your wondering :-)

>You could also use a validation framework such as FormProc.
That's nice, I'm going to take a look at it.

Thanks again for your feedback :-)

Best regards,
Luigi.

Read your article, and it seems that you are caught in the try/throw/catch as a control statement, like a if/then/else, or swithc/case statement, verses try/throw/catch for the controlled handling of unknown system exceptions.

If you look at most of the Java API, most of the exceptions seem to come from a murky underworld where the operating system may have misbehaved or the network has dropped out from under you. During normal the flow of operation, you should use the historical "c" style control statements and reserve exceptions for the truely unexpected.

Performance wise, exceptions have been a really dog (at least in my background of c++). Exceptions in Java, might be exactly the same, but I'm still becoming familiar with Java's underpinnings.

I'd opt for using OO methods for validation, but save exceptions for the truely unexpected.

Noah

This reminds me of a series of articles posted on javaworld, where the author looked at form validation through generation of java classes from xml schema. The author started off with throwing exceptions to indicate a validation problem, but in his final article, preferred recording all errors in a HashMap and then, if not empty, dealing with each error.

We took this idea on board on a project I am working on now, we have slightly modified the CastorXML framework to produce a set of java classes that can validate an XML stream, but whereas Castor normally throws an exception when an XML stream cannot be validated against a schema or DTD, we instead return a HashMap containing all validation errors.

We then apply XSLT to transform our XML schema into Velocity template pages. The idea is that each form we need to represent, can be represented by a complexType in XML Schema, and each of the elements of the complexType can represent a parameter on the form. Using the redirect:write extension of Xalan, we can create the necessary files without having to do any manual modification.

The Velocity templates that are generated have place holders for our error fields, and are by default made 'invisible'. So at runtime, our user submits a form, we put the parameters into an XML format that is expected by our Castor generated classes, it figures out which complexType the XML should be validated against, validates, returns a HashMap, if the HashMap is not empty, we simply fill a VelocityContext with the values from the HashMap, and we send back to the user. So far it seems to work well and we haven't found any difficulties with this approach. Best thing is that all our information is one file, our original xml schema document.

Daffy

Sorry, forgot to put a link to the javaworld article I referred to in my above post.

http://www.javaworld.com/javaworld/jw-12-2000/jw-1208-validation4.html?

Exceptions tend to be extremely heavyweight, and should be used when "exceptional" cases occur, such as resources not available anymore, state is inconsistent and processing cannot continue, etc.

Consider server-side validation from within your value object or from an external utility and returning a series of keys that correspond to messages in a resource bundle - see Struts for this example and the Struts Validation Framework as an extension for better validation capabilities. Exceptions should only be thrown from within the web tier during failures communicating to the business tier, as well as from business APIs themselves in the business tier. Whether you are using EJBs are not, this separation of the web and business tiers is essential to having a maintainable system.

By putting the validation in or near the value object that has the information submitted to the user, you are ensuring that the validation is done on the server side should the client side fail, while not using a language construct improperly. Exceptions are not to be used loosely, nor as conditional blocks.

Regards,
James

I can agree with most of comment about the "improper use" of exceptions. I also think it's a "different" use of exception, not so improper, cause we are managing validation issue that would be treated as exception for example in a standalone app. But I find them as very interresting comments. Thanks all.
But I really don't think that performance loss due to exception mechanism is a real issue. I wrote different apps, since 1 year ago, optimizing everithing else, like includes, forwarding etc. But I never noticed about increasing of delay time of this option.
Exceptions in this way happens just when the user miss something and also maybe we can have a response delayed of a couple of millisecods, but I don't believe it really does matter. Also, comparing this approach with many other apps I've seen, I can say that's quite more easy to manage and to understand; most of people in the company in wich I am providing consulting are going to adopt this "pattern" freely.

I would to thank all of you. Reading your comments I started to think more in deep to this solution, and about possibly related problems that never touch my mind before.

Regards,
Luigi

I dont have our testing results right here but Exceptions are phenominally expensive. What makes them so expensive is the I/O involved in their marshalling. That I/O is pretty damn expensive to marshall just within the VM but that problem explodes when you bring a multi-tier application. Although you may run all the tiers in the same app server it may be that the app server marshalls the I/O as in a multi-tier application but in memory. For instance, containers that do RMI/IIOP often actually marshall the IIOP in memory, meaning the impact becomes huge.

Also you are making an assumption that the developer calling into your servants fully understands your intent with all of these exceptions. Bad to assume. (Although the pattern of using Exceptions with try/catch blocks to create 'logical units of work' is compelling from a developers perspective).

Overall Exceptions should be used for Exceptional circumstances. Not as a message passing structure.

Dave Wolf
dave at getpersonified dot com

In our project, we try to be 'active' and not 'reactive'. We try to control every validation actively in the JSP, and not to act when some error has happened.

There is also a way to avoid some situations, modifying the construction of the page-design. For example, if the user has to set a date, it's possible to make an error. But if you create a calendar, or select the date with lists, or things like this, it's not possible to make a mistake...! Simply

That's the happy way. Many times you are forced to do a server side validation not only on the data you entered.
example:
if you need to insert a product but must verify that the name of the product isn't allready inserted you are forced to do a server side validation.