NOTE: Some people
may not have recieved attached sample files, they seem to have been bounced
back due to size so they have been removed
They can be found at the
following locations:
Hello
all,
I have attached a sample validation framework that I have been working on and have implemented a similar approach on a few sites to date. This all may seem very complicated at first, but once the system is in place, maintenance and development are a piece of cake. The basic concept is to extend a design pattern where by within a set of client side JS files there can be a series of separated mechanisms for handling validation code: throwing errors, collecting errors, and presenting errors. By separating out these three sets of functionality you can utilize a separate unique handler for presentation of error messages. If you approach client side code with a concept that JS code is not necessarily part of the "View", than approaches similar to this lend JavaScript to extend itself as a "real" programming language. This approach is similar to general MVC patterns for Java Code in that it is really not the job of your validation code to present errors, presentation is part of "a view" and should not reside in business logic. So you may be asking how or what this all has to do with STRUTS??? Well, by combining the intricicies of the STRUTS action class with a separate pseudo MVC layer at the front end, a validation error in an action class can catch that error and not only display it, but hand it off to a controller at the JavaScript tier. Each error within the Application Resource file can be utilized to call a set of client side code. So why is this a benefit you might ask?? By passing a validation error through a handler at the client side tier, you can ensure that both client side and server side validation are presented to the user in the same manner thereby enhancing the user's experience within an application and opening the world of possibilities for how a server can pass massages back to a user. This approach could be very easily extended(and I have) to pass errors back as a series of red text on the page, a highlighted text field, an alert box(as in the sample), a spinning images red diamond next to a field, or even into a full fledged "Agent" or similar device that is much more user friendly. Additionally this approach only requires maintenance of one set of error messages across both the front end (JavaScript) and the backend (STRUTS) validation which all resides in the Application Resource file for easy maintenance by any developer or layperson. The basic scenario on how the system works is that by utilizing the STRUTS errors.header and errors.footer in the appResources.properties file to begin a JavaScript statement similar to: errors.header=<script language="JavaScript">clientSide=false; errors.footer=collectErrors();clientSide=true;</script> >From there each error message within the appResources.properties file contains the text of the error message, but places it within a JavaScript method to pass the handling of that error to a function on the front end similar to the following: error.userNameEmpty=throwError("","generic","User Name"); error.userNameNumeric=throwError("All User Names must contain at least 1 number","specific",""); Within the body of the JSP file, the STRUTS <html:errors /> tag is used, and if there is an error or even a few on the page, code similar to the following will be output with the JSP when the response is sent back: <script language="JavaScript"> clientSide=false; throwError("","generic","User Name"); throwError("All User Names must contain at least 1 number","specific",""); collectErrors(); clientSide=true; </script> Each of these lines is very unique to this implementation, but the concept is simple, tell the JS pseudo controller that it is the server throwing these errors, hand the errors to the JS throwError method to instantiate new client side pageError objects; have the collectErrors method collect any errors that have been thrown and pass them to a presentation method (presentErrors), then return the control to the client so as the user fixes errors they can be revalidated at the client side before causing another server hit. This leads to the notion of performing both client side and server side validation on data to try and avoid extra hits to an application and avoid sending data to the backend for meaningless checks that could have been handled prior to the request going out. Now I am not saying that any server side validation should be removed as both are necessary to ensure the stability and robust ness of a system, but a pure server side approach is not the answer, and a pure client side approach is inadequete. So to merge the two worlds together there needs to be one more step, and that is to have the set of client side validation code, call the same set of error messages that the server will be using so as to only have to maintain one baseline. Again, by treating the Web Tier(front end) as its own smaller MVC system, there becomes a true sense of abstraction even within that set of code. The JSP page itself along with the presentError method provide the true "View" portion of the system, the throwError handler and collectError method provide the controller for how errors are handled by the system along with what business logic to run for a particular page(error_Login,js). The error_Login.js file contain the page specific validate() function that notes what functions should be called for that page: function validate() { // Run page specific functions declared in .jsp file so error messages can be stored in appResoucres.properties file checkUserName(); checkPassword(); // Execute the collectErrors method to display any errors that are present or submit the form collectErrors(); } The model portion of the system where data is received within the business logic is encapsulated within the page specific JavaScript file that has the JSPfile extension(error_Login.jsp). The code within this page contains the actual validation code for the specific fields on the page along with a <bean:message> implimentation to extrapolate error messages for a particular case from the appResources file and populate the JavaScript validation code(hence the JSP file type): function checkUserName(){ if(!validateNotEmpty(document.loginForm.userName.value)){ <bean:message key="error.userNameEmpty"/> }else{ if(!validateNumeric(document.loginForm.userName.value)){ <bean:message key="error.userNameNumeric"/> } if((document.loginForm.userName.value.length < 7)||(document.loginForm.userName.value.length > 25)){ <bean:message key="error.userNameLength"/> } } } As the page is displayed, the client side validation code is populated with the same code snippets as were thrown earlier by the <html:errors /> tag: function checkUserName(){ if(!validateNotEmpty(document.loginForm.userName.value)){ throwError("","generic","User Name"); }else{ if(!validateNumeric(document.loginForm.userName.value)){ throwError("All User Names must contain at least 1 number","specific",""); } FLOW OF EVENTS As the user clicks on the submit button of a form, first the error_Login.js file gets called from its validate() function this then tells the browser to call the checkUserName() and checkPassword() functions within the error_Login.jsp file which has received the set of error messages from the Application resource file as the page was displayed. If one of the client side functions returns an error on a field, they will call the throwError() method within the error_Lib.js file which will created a new pageError object and populate it with what type of error and what field had a problem or what specific message to display. Scripting within the error_Login.jsp file can determine whether to keep collecting errors or return after a crucial one is reached. After all validation is completed in the JavaScript tier, control is passed to the collectErrors() controller. It will determine if any errors have occurred and if so pass those along to the presentErrors() handler otherwise it will submit the form to the backend for the action class to begin its work. If an error occurs within an action class Validation method, it will be passed along and will eventually follow the same mechanism thereby eliminating two code bases for error messages and possibly dissimilar presentation of them to a user. I think that is enough to at least intrigue some questions, I would be happy to entertain any questions and help out with any problems. Currently I am working on extending the framework to include a GUI tool for configuring the presentation of the error messages, as well a separate system for "content management" of error messages so a business or content person can avoid working directly with a text file. Also I have been intrigued by the current Validator system that many are utilizing and look forward to encompassing some method of directly creating both sets of validation code(front end and back end) automatically. There are 2 very small versions of the sample attached, the one labeled "flat files" is pure HTML w/ JavaScript to at least show the mechanism in place without having to modify any existing STRUTS application, and the STRUTS folder contains nearly identical code following the full path above, but will require some configuration. Thanks, Adam S. Grohs [EMAIL PROTECTED] ----- Original Message ----- From: "Adam Grohs" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, September 30, 2001 2:11 PM Subject: Re: Javascruot with html:errors > Martin, > That is correct, the stuts error tag cannot actually invoke a JavaScript > method, however it can write one out to the screen and have the browser > throw such an error at run time of the page. I will be posting a follow up > thread to explain what throwError() (the JavaScript form my response) might > do with a sample set of code. Without violating any code ownership issues > for the specific implimentation developed for the site listed below, the > general concept and a sample modified implimentation will be available in a > new thread I am going to post in a few hours. Please see the "JavaScript > with html:errors - new STRUTS validation" thread coming up very soon, I am > just putting the finishing touches on the files. > > Thanks, > Adam S. Grohs > [EMAIL PROTECTED] > > > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, September 29, 2001 1:08 PM > Subject: Re: Javascruot with html:errors > > > > Adam, > > > > This is an interesting idea. I'd certainly be interested in hearing more > > about what throwError() does, and what happens when more than one error > > occurs on a page. > > > > I still claim that you are not actually calling JavaScript from the tag, > > though. You may be generating it, but you're not actually calling it. > > However, perhaps this is what the original poster was asking for. :-) > > > > -- > > Martin Cooper > > > > > > ----- Original Message ----- > > From: "Adam Grohs" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Saturday, September 29, 2001 8:30 AM > > Subject: Re: Javascruot with html:errors > > > > > > > This response is not necessarily true. It is possible to call a > > particular > > > JavaScript method or function from the <html:errors /> tag. I worked on > a > > > team from iXL, Inc. and we have just completed a very sophisticated > error > > > handling mechanism for www.hallmarkstories.com that allows errors to be > > > thrown by an action class through the struts error tag and then each > error > > > that is thrown refers to a specific key in the AppResource.properties > file > > > that invokes a Javascript method for throwing a client side error. This > > > allows both server-side and client-side validation to be handled by one > > set > > > of presentation layer code. I would be very happy to explain the > details > > > further if you would like more information. > > > > > > Ex. > > > error.header=<script language="JavaScript"> > > > error.email.invalid=throwError("Please enter a valid email > > > address") > > > error.header=</script> > > > > > > Adam S. Grohs > > > > > > ----- Original Message ----- > > > From: <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Monday, September 24, 2001 12:06 AM > > > Subject: Re: Javascruot with html:errors > > > > > > > > > > If I understand what you're asking, it's not possible. JavaScript is > > > > executed at the client (e.g. the browser), while JSP, including the > > > > <html:errors> tag, is executed on the server. > > > > > > > > -- > > > > Martin Cooper > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Francois Duchaussoy" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Sunday, September 23, 2001 9:13 PM > > > > Subject: Javascruot with html:errors > > > > > > > > > > > > > Hi, > > > > > > > > > > Would anyone know how to call a javascript method from a > > <html:errors/> > > > > tag? > > > > > Basically I would like to highlight a field where an error occurs... > > > > > > > > > > Any ideas?? > > > > > Francois. > > > > > > > > > > > > > > > > > > > > > > |