I agree. Currently I do something like that in my own code (really looking
forward to replacing it thought :) ):
def validMember_? = {
val errorChecks =
(if (member.userId == "") { S.error("You must provide a user Id");
false } else true) ::
(if (member.userId.length < 6) { S.error("User Id must be at least 6
characters"); false } else true ) ::
(if (member.givenName == "") { S.error("You must provide a first
name"); false } else true ) ::
(if (member.surname == "") { S.error("You must provide a last name");
false } else true ) ::
(if (member.birthdate == null) { S.error("Invalid birthday"); false }
else true ) ::
(if (member.email == "") { S.error("You must provide an email
address"); false } else true ) :: Nil
errorChecks forall(_ == true)
}
The trick is to order them so that that the messages make sense in context.
Note my two checks on member.userId...
Derek
On Tue, Sep 23, 2008 at 1:35 PM, Charles F. Munat <[EMAIL PROTECTED]> wrote:
>
> Oliver Lambert wrote:
> > Do/should validations stop at the first error message on the field, at
> > least by default?
>
> I much prefer that they do not. It really irritates me when I'm using an
> online form and it tells me that something is invalid, then I fix it,
> resubmit, and get a new error.
>
> I'd much rather get a list of errors at the top of the form with the
> fields in error highlighted, or highlighted fields with the error
> messages either displayed at the field or as a mouseover popup (probably
> the former).
>
> In fact, ideally I like my forms to:
>
> 1) indicate which fields are required and which are optional,
>
> 2) give an example, when useful, of expected input (or the validation
> rule, such as "must be greater than 100"),
>
> 3) either prevent invalid input completely (e.g. preventing input of
> letters to a field that takes digits), or provide some sort of
> visual/audible indication of when the validation rule has been
> satisfied, such as a password field that indicates password strength and
> the minimum required, or a zip code field that indicates when the zip
> code entered matches the RegEx used to validate it.
>
> And, of course, I want the back end to validate as a fallback and to
> generate enough error output to permit the form to do 1-3 above. With
> AJAX, the form could actually validate using the back end as you tab
> from field to field (although if AJAX is working, so is JavaScript, so
> that's probably unnecessary).
>
> Having spent a lot of time in the past working with the W3C's Web
> Accessibility Initiative (WAI), I tend to be attentive to accessibility
> concerns and try to design all my sites to be usable and accessible to
> persons with disabilities -- visual, cognitive, motor, etc. Forms are
> always tricky for persons with disabilities.
>
> Chas.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
