RE: Client Validation Design Discussion

[Hagen, Nicholas]

I have developed my own Client validation framework for the company I work for and I will second the notion of what Trinidad/ADF is doing.  I went a similar approach, although I did mine slightly differently.  We have a requirement to support multiple mediums including desktop, PDA, etc.  So, I developed an interface (ClientValidator) that defines the basis of the system.  Then, I developed further interfaces that extend ClientValidator for HtmlClientValidator and WmlClientValidator.  These interfaces define the appropriate functions required for a specific technology.  Although most mediums will just require access to some appropriate resource script or script content, some mediums may require additional functionality.  Then, a specific validator can choose to implement one or more client validators depending on which medium they want to support.  This is prolly overkill for most situations, but it allows for future interfaces that classes can implement.   So, IMO, +1 for an interface as well.   Nick   From: Adam Winer [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 12, 2006 11:34 AM To: MyFaces Development Subject: Re: Client Validation Design Discussion   I think that having a ValidatorBase is reasonable enough, but that it's critical to make the real API an interface in this case.  We can't require that everyone on the planet extend from ValidatorBase if they want to take part in this.  For one example, what if I download a third-party validator, and want to add client-side validation support to it? So, +1 for an interface. I'd also be -1 against being able to set it on an individual validator level;  wait 'til someone says it is necessary, and justifies that need. Regarding the name of an interface - does MyFaces have a standard to preface interfaces with a capital I?  JSF doesn't do that in the standard, nor does much of anything I know of in J2EE.  I'd be -1 on using a capital I prefix. FWIW, it would be nice to also look at the Trinidad ClientValidator API; here's a link to the Javadoc of the ADF version of that: http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/apidocs/oracle/adf/view/faces/validator/ClientValidator.html Also, recognize that client-side validation is only half of the picture;  you also need client-side converters.  Trinidad has an API for that too: http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/apidocs/oracle/adf/view/faces/convert/ClientConverter.html -- Adam On 7/12/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: Hi Cagatay! > One more discussion topic, the client validation is turned on/off via > a context parameter, org.apache.myfaces.ENABLE_CLIENT_VALIDATION, > Do you think validators should override this global setting via an > attribute like client? client=true|false - yes, I think this will be a nice feature to have. Not that I really think that this will be widely used, but currently you are "knee deep" ;-) in the validator stuff, so lets add it to ValidatorBase too - and who knows what the users wanted to have later. Ciao, Mario