RE: Data Validation
I posted this to struts-dev, but not to struts-user. I have a basic validation framework using regular expressions and I made an example struts application. The validation rules are stored in the validation.xml file. Having a java.text.Format class is nicer since it is locale based and also converts a string to another object. When I've had to convert a string to an another object, I've used regular expressions to get the pieces of the string that I want and then convert them to a date, for example. http://home.earthlink.net/~dwinterfeldt/ David Winterfeldt --- Ted Husted <[EMAIL PROTECTED]> wrote: > >In our case, we have chosen to use the > java.text.Format as a > superclass of > >all our validation and formatting classes. > > Can you provide working examples of any of the > classes you are using > now? > > Putting something like this into a sample Struts > application can really > help move things along. > > >Beyond the simple aspect of validating the format > of an input string, > it is > >also often required to transform the validated > string into a usable > form for > >further processing. > > >Eventually, beyond the use of Format classes, we > intend to create a > sort of > >format class instance pool, whereby pre-initialized > format classes are > >stored for repetitive usage. This avoids the > creation and > initialization of > >an object each time a validation/formatting has to > be performed. The > Struts > >digester would be a great tool for initializing > this pool. > > A big example of that is inserting the value into a > JDBC DBMS. Here, it > can be convenient to use a string-based entity bean > to work with the > Struts form, and then let the driver do the final > conversion of the > validated sttring. A pool of JDBC-orientated > validation classes sounds > be very useful. > > If you haven't already, you should consider > subscribing to the > Struts-Dev too, where there is more talk about how > to extend Struts. > > > > > > > > > > > Could you provide a simple example of how you use > the java.text.Format > class to validate some standard types. For example, > a form with fields > like: > > Date > Name > Amount > Telephone Number > > > > An important reason for validation, as you point > out, is for later use > of the value, especially the insertion of the value > into the database. > > > > > *** REPLY SEPARATOR *** > > On 2/6/2001 at 8:12 AM Rey Francois wrote: > > >In our case, we have chosen to use the > java.text.Format as a > superclass of > >all our validation and formatting classes. I would > suggest Struts to > >consider this approach. Our decision derives from > the following > >requirements: > > > >1 Validation of Strings data according to a > specified format > >The basic requirement is to validate that a string > complies to a > specified > >format. For example, for a string representing a > date, the requirement > is to > >make sure it is of the form: dd/mm/. > > > >2 Parsing Strings to Objects and vice-versa > >Beyond the simple aspect of validating the format > of an input string, > it is > >also often required to transform the validated > string into a usable > form for > >further processing. In Java this means creating an > object instance > from the > >string. With the date example, this could mean > creating a > java.util.Date > >object. > >On the other hand, it is also required to perform > the reverse > operation. In > >the case of an instance of a java.util.Date, it > should be possible to > get a > >string representation of it according to a > specified format. > > > >3 String buffer parsing and formatting > >It should be easy to parse only a certain part of a > larger string when > the > >latter contains the formatting of several elements. > Conversely, it > should be > >easy to append the string representation of an > object to an existing > string. > >This can be useful for example in the context of > marshalling object > >instances into an XML representation. > > > >4 Independence of the usage context > >The classes involved should be coupled to any > context of usage. This > is to > >allow maximum reuse of the logic in various > contexts. For example the > >framework should not depend on the HTTP request of > the Servlet API. > >This should enable the creation of a library of > formatter that can be > used > >in various projects. This library can contain basic > formatters, but > also > >more business oriented ones such as account number > formatting, etc. > > > >5 Internationalization > >In some cases it is necessary to have the parsing > and validation > processing > >aware of locale-specific factors. The date example > is again a very > good > >illustration of this requirement, whereby in the > United States dates > are of > >the form mm/dd/, while in Europe dates are of > the form dd/mm/. > In > >the context of a graphical user interface, this is > an important > requirement. > > > >The java.te
RE: Data Validation
Struts >digester would be a great tool for initializing this pool. > >Comments welcomed! > >François Rey >Financial WebSuite >The Capital Markets Company >http://www.capco.com/ > > >-Original Message- >From: Ted Husted [mailto:[EMAIL PROTECTED]] >Sent: 06 February 2001 01:01 >To: Struts List; [EMAIL PROTECTED] >Subject: Re: Data Validation > > >On 2/4/2001 at 11:52 PM Neal Kaiser wrote: >>Just wondering... Where do people typically do their validation? In >the >>ActionServlet or ActionForm? Are there any pros/cons? > >Validation is still rather controversial. Some people bypass the Struts >mechanism completely. > >Typically, you would start by validating the type and range of data in >ActionForm. Once that passes, you might need to do some further >"business logic" validation in the ActionServlet; for example, to check >a login from a database. > > >*** REPLY SEPARATOR *** > > >>Has anyone thought about adding data validation tags to the Struts >taglibs? >> >>For example, what if we could do: >> >>validationtype="varchar" /> >> >>or something like that. >> >>Could it not generate the necessary javascript, as well as provide an >easy >>to use >>interface for detecting and reporting errors in the Action.perform()? >> >>Just wondering... Where do people typically do their validation? In >the >>ActionServlet >>or ActionForm? Are there any pros/cons? >> >>Thanks, >>Neal > > > >-- Ted Husted, Husted dot Com, Fairport NY USA. >-- Custom Software ~ Technical Services. >-- Tel 716 425-0252; Fax 716 223-2506. >-- http://www.husted.com/about/struts/ > > >*** * >The information in this email is confidential and is intended solely >for the addressee(s). >Access to this email by anyone else is unauthorised. If you are not >an intended recipient, you must not read, use or disseminate the >information contained in the email. >Any views expressed in this message are those of the individual sender, >except where the sender specifically states them to be the views of >The Capital Markets Company. > >http://www.capco.com >*** -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/about/struts/
RE: Data Validation
In our case, we have chosen to use the java.text.Format as a superclass of all our validation and formatting classes. I would suggest Struts to consider this approach. Our decision derives from the following requirements: 1 Validation of Strings data according to a specified format The basic requirement is to validate that a string complies to a specified format. For example, for a string representing a date, the requirement is to make sure it is of the form: dd/mm/. 2 Parsing Strings to Objects and vice-versa Beyond the simple aspect of validating the format of an input string, it is also often required to transform the validated string into a usable form for further processing. In Java this means creating an object instance from the string. With the date example, this could mean creating a java.util.Date object. On the other hand, it is also required to perform the reverse operation. In the case of an instance of a java.util.Date, it should be possible to get a string representation of it according to a specified format. 3 String buffer parsing and formatting It should be easy to parse only a certain part of a larger string when the latter contains the formatting of several elements. Conversely, it should be easy to append the string representation of an object to an existing string. This can be useful for example in the context of marshalling object instances into an XML representation. 4 Independence of the usage context The classes involved should be coupled to any context of usage. This is to allow maximum reuse of the logic in various contexts. For example the framework should not depend on the HTTP request of the Servlet API. This should enable the creation of a library of formatter that can be used in various projects. This library can contain basic formatters, but also more business oriented ones such as account number formatting, etc. 5 Internationalization In some cases it is necessary to have the parsing and validation processing aware of locale-specific factors. The date example is again a very good illustration of this requirement, whereby in the United States dates are of the form mm/dd/, while in Europe dates are of the form dd/mm/. In the context of a graphical user interface, this is an important requirement. The java.text.Format class satisfies all the above requirements. It is a standard Java object, so using it should be consistent with future Java developments. Finally, J2SE already proposes some formatters for numeric values, date, and messages. In our context, these format classes will be used for: - HTTP request parameter validation - Handling of request and return buffer to and from legacy systems - Displaying of the data elements in an HTML front-end Eventually, beyond the use of Format classes, we intend to create a sort of format class instance pool, whereby pre-initialized format classes are stored for repetitive usage. This avoids the creation and initialization of an object each time a validation/formatting has to be performed. The Struts digester would be a great tool for initializing this pool. Comments welcomed! François Rey Financial WebSuite The Capital Markets Company http://www.capco.com/ -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: 06 February 2001 01:01 To: Struts List; [EMAIL PROTECTED] Subject: Re: Data Validation On 2/4/2001 at 11:52 PM Neal Kaiser wrote: >Just wondering... Where do people typically do their validation? In the >ActionServlet or ActionForm? Are there any pros/cons? Validation is still rather controversial. Some people bypass the Struts mechanism completely. Typically, you would start by validating the type and range of data in ActionForm. Once that passes, you might need to do some further "business logic" validation in the ActionServlet; for example, to check a login from a database. *** REPLY SEPARATOR *** >Has anyone thought about adding data validation tags to the Struts taglibs? > >For example, what if we could do: > > > >or something like that. > >Could it not generate the necessary javascript, as well as provide an easy >to use >interface for detecting and reporting errors in the Action.perform()? > >Just wondering... Where do people typically do their validation? In the >ActionServlet >or ActionForm? Are there any pros/cons? > >Thanks, >Neal -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/about/struts/ The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those
Re: Data Validation
On 2/4/2001 at 11:52 PM Neal Kaiser wrote: >Just wondering... Where do people typically do their validation? In the >ActionServlet or ActionForm? Are there any pros/cons? Validation is still rather controversial. Some people bypass the Struts mechanism completely. Typically, you would start by validating the type and range of data in ActionForm. Once that passes, you might need to do some further "business logic" validation in the ActionServlet; for example, to check a login from a database. *** REPLY SEPARATOR *** >Has anyone thought about adding data validation tags to the Struts taglibs? > >For example, what if we could do: > > > >or something like that. > >Could it not generate the necessary javascript, as well as provide an easy >to use >interface for detecting and reporting errors in the Action.perform()? > >Just wondering... Where do people typically do their validation? In the >ActionServlet >or ActionForm? Are there any pros/cons? > >Thanks, >Neal -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/about/struts/
Re: Data Validation
These items are on the TODO list for the 1.1 timeframe. + Client Side Validation. Add the ability to automatically generate optional JavaScript code to perform client-side validations for things like required fields, numeric fields, dates/times/timestamps, and so on. The required validation should mesh with validation enhancements provided in the controller servlet itself. + Standard Validations. Add the ability to configure standard validations on particular properties to be enforced by the controller servlet automatically. Where feasible, client-side JavaScript validations may also be generated based on the same configuration rules. *** REPLY SEPARATOR *** On 2/5/2001 at 6:07 PM Jim Richards wrote: >>Has anyone thought about adding data validation tags to the Struts taglibs? > >This came up quite some time ago. I have a requirement for this sort >of thing, and posted a library with example for doing validation >(not sure where it is now). > >It work on the client side in JavaScript and you specify the >function you want to use for validation, and the message >to display, it piles them all up and displays it in a window.alert() >with all the errors, and jumps to the first field with the >error. It mostly works as there are some freaky things with hidden >fields it doesn't like. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/about/struts/
Re: Data Validation
>Has anyone thought about adding data validation tags to the Struts taglibs? This came up quite some time ago. I have a requirement for this sort of thing, and posted a library with example for doing validation (not sure where it is now). It work on the client side in JavaScript and you specify the function you want to use for validation, and the message to display, it piles them all up and displays it in a window.alert() with all the errors, and jumps to the first field with the error. It mostly works as there are some freaky things with hidden fields it doesn't like.
Re: Data Validation
I think the regular expression version (eg http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-struts_p.html ) is much better, becouse jou can easely write a client side validation with the same regexp. ( have it working except for the stupid checkboxes and radio buttons in ie4+, I keep "losing" my properties)and the regexp object is part of javascript since version 1.1(I thought, browser NS3+, ie4+). - Original Message - From: "Neal Kaiser" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, February 04, 2001 8:52 PM Subject: Data Validation > Has anyone thought about adding data validation tags to the Struts taglibs? > > For example, what if we could do: > > > > or something like that. > > Could it not generate the necessary javascript, as well as provide an easy > to use > interface for detecting and reporting errors in the Action.perform()? > > Just wondering... Where do people typically do their validation? In the > ActionServlet > or ActionForm? Are there any pros/cons? > > Thanks, > Neal >
