Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of awiner@gmail.com designates
 66.249.92.168 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=mI/aK91MZVkqTyn6rxbQ9UySK8Jwyv+MLUyL5+erKwg2U3MOPKtvhzm+pgNg0FWoGvc+9nh2TnMkJyFG7guEeI/YXR7Z/vDSgLAp4+r6JhrtvxvUlqATdkr5fKrFmLtWemlJtVb7t+rE/XyoVipyX6VXVFPPOqTwRWUAnAMIuAY=
Message-ID: <6dac79b90607121448t154b33ecs5d3e432c1dceaeaa@mail.gmail.com>
Date: Wed, 12 Jul 2006 14:48:45 -0700
From: "Adam Winer" <awiner@gmail.com>
To: "MyFaces Development" <dev@myfaces.apache.org>
Subject: Re: Client Validation Design Discussion
In-Reply-To: <8c9d4eaa0607121441n35ba4ad5n39d13d5d5f710d36@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_14683_4560222.1152740925046"
References: <8c9d4eaa0607120350y2d3c9f53wd96f9caec71826bb@mail.gmail.com>
	 <44B4D9DF.2070507@ops.co.at>
	 <8c9d4eaa0607120423i7c9297e1o4baf82ca5a79bb1b@mail.gmail.com>
	 <44B4DD5D.5000309@ops.co.at>
	 <6dac79b90607120933y5a99000bp3c75dcda88b19f05@mail.gmail.com>
	 <44B54E7C.8030006@ops.co.at>
	 <71235db40607121348g46547154t14009871059b3c33@mail.gmail.com>
	 <8c9d4eaa0607121441n35ba4ad5n39d13d5d5f710d36@mail.gmail.com>

------=_Part_14683_4560222.1152740925046
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 7/12/06, Cagatay Civici <cagatay.civici@gmail.com> wrote:
>
> Hi,
>
> Although I fancy the interface design first because of the flexibility,
> since enabling all of the myfaces extended validators to do validation at
> client is necessary, validatorbase still seems the better way. Validatorbase
> is also a nice place for the common client attribute. Anyway maybe a vote is
> needed for the design choice?
>


It's not either one or the other.  We can do both.  Create a validator
interface, *and* make ValidatorBase implement it.  What's the downside?

About the "I" prefix, yes let's forget about it.
>
> Also the client side converters issue, I believe client validation is more
> than the half of the picture because most of the client validators do not
> need any conversion on the input. Some examples are; required attribute,
> length, email, url, equality, regular expression, credit card, isbn. The
> ones that need conversion at client side might be range and compare.
>

But that overlooks all the "validation" done by converters - number
formatting and date formatting in particular.

-- Adam


By the way, these validators run only at onsubmit event of the form. I've
> also implemented simple "onkeypress validation" that allows only integers to
> be entered when there is an integeronly converter by disabling letters, or
> max-min length validation when there is a length validator. I think these
> could be very useful too, what are your thoughts on this? If we all agree,
> I'll include it too.
>
> Cheers
>
> Cagatay,
>
> www.jroller.com/page/cagataycivici
>

------=_Part_14683_4560222.1152740925046
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 7/12/06, <b class="gmail_sendername">Cagatay Civici</b> &lt;<a href="mailto:cagatay.civici@gmail.com">cagatay.civici@gmail.com</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Hi,<br><br>Although I fancy the interface design first because of the flexibility, since enabling all of the myfaces extended validators to do validation at client is necessary, validatorbase still seems the better way. Validatorbase is also a nice place for the common client attribute. Anyway maybe a vote is needed for the design choice?
</div></blockquote><div><br>&nbsp;</div><div>It's not either one or the other.&nbsp; We can do both.&nbsp; Create a validator interface, *and* make ValidatorBase implement it.&nbsp;  What's the downside?<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>About the &quot;I&quot; prefix, yes let's forget about it.<br><br>Also the client side converters issue, I believe client validation is more than the half of the picture because most of the client validators do not need any conversion on the input. Some examples are; required attribute, length, email, url, equality, regular expression, credit card, isbn. The ones that need conversion at client side might be range and compare.
</div></blockquote><div><br>But that overlooks all the &quot;validation&quot; done by converters - number formatting and date formatting in particular. <br><br>-- Adam<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>By the way, these validators run only at onsubmit event of the form. I've also implemented simple &quot;onkeypress validation&quot; that allows only integers to be entered when there is an integeronly converter by disabling letters, or max-min length validation when there is a length validator. I think these could be very useful too, what are your thoughts on this? If we all agree, I'll include it too.
<br><br>Cheers<br><br>Cagatay,<br><br><a href="http://www.jroller.com/page/cagataycivici" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.jroller.com/page/cagataycivici</a><br>

</div></blockquote></div><br>

------=_Part_14683_4560222.1152740925046--