You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by mi...@siemens.com on 2004/10/07 16:04:07 UTC

Enhanced client side validation

We have a requirement to validate (using Javascript) beans whose properties
can be of type Map, List, [], or any simple type. Furthermore, Maps, Lists,
and []s can be arbitrarily nested.
 
We have found that the validator only supports simple properties (on the
client). We modified it last year to support Lists and []s. Now we want to
modify it to support Maps and nesting.
 

Here's how it currently works:
 
Suppose a user has a List of addresses:
 
 public class User {
  public List getAddresses() {
   ...
  }
 }
 
and an address has a zip:
 
 public class Address {
  public String getZip() {
   ...
  }
 }
 
So in validation.xml we write:
 
     <form name="user">
         <field 
          property="zip"
          indexedListProperty="addresses"
    ...
 

What we would rather do is write:
 
     <form name="user">
         <field 
          property="addresses.zip"
    ...
 
or
 
         <field 
          property="addresses[].zip"
    ...
 

Then we can expand this to support nesting and Maps:
 
   <!-- validates all areaCodes -->
         <field
          property="addresses[].phoneNumbers[].areaCode"
    ...
 
   <!-- addresses is of type Map now; validates areaCodes 
        for shipping address -->
         <field
          property="addresses(shipping).phoneNumbers[].areaCode"
    ...
         <field
 
   <!-- validates all areaCodes -->
          property="addresses().phoneNumbers[].areaCode"
    ...
         <field
 
   <!-- validates areaCodes for shipping address and phone 
        numbers that start with home (i.e. home, home1, 
     home2, etc.) -->
         <field 
          property="addresses(shipping).phoneNumbers(home*).areaCode"
    ...
 
Note the wildcard in the last example.
 
Please let us know if this has been done before; if there's a better
approach; or if you would like the code for yourself.
 
Thanks,
Mike Dunn
mike dot dunn at siemens dot com