Cagatay
On 7/13/06, Hagen, Nicholas <
[EMAIL PROTECTED]> wrote:
IMO, I still think the methods should not refer to JS in the method names. If the client validator is not specific to a specific platform (html, wml, etc), then it should just have a method to getScriptFunction rather than something specific like getJsFunction. I realize almost every system uses JS, but for those that don't it is somewhat misleading. Of course, in those situations they could just extend the interface for their needs, but I think a generic interface is better.
Nick
From: Cagatay Civici [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 13, 2006 1:15 AM
To: MyFaces Development
Subject: Re: Client Validation Design Discussion
Hi,
No actually, I was talking about the ClientValidator interface I've used when working on the sandbox validators but hey this one is very similiar too. My interface has methods like getJsFunction and getParams and the one in the adf has also similiar methods to get the js code.
CagatayOn 7/13/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
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
