Are you talking about this http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/apidocs/oracle/adf/view/faces/validator/ClientValidator.html
-Matthias On 7/12/06, Cagatay Civici <[EMAIL PROTECTED]> wrote:
Hi, After brainstorming on the issue more, I think Adam's suggestion looks like the optimal one. ValidatorBase will implement ClientValidator interface and third party validators should also join the client validation mechanism by using the interface. So the answer seems to be using them both for now. Cagatay On 7/13/06, Hagen, Nicholas <[EMAIL PROTECTED] > wrote: > > > > > > 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 > > >
-- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
