Derek Chen-Becker wrote:
> If you want to tell them to enter a value, I'm sure that you could
> write (if it doesn't already exist) a notEmpty validation that would
> say the right thing and do something like:
>
> val validations = notEmpty("You must provide an email address") _ ::
> valRegex(...
Or, you could use PartialFunctions so that you could write:
validations = notEmpty(...) orElse valRegex(..) :: super.validations
The general idea of lists of validators works. Using Scala's facilities
rather than inventing complex structures means that your validation code
will read like much of your other code.
Thanks,
David
>
> Derek
>
> On Tue, Sep 23, 2008 at 9:41 AM, Oliver Lambert <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>
> On 24/09/2008, at 1:00 AM, David Pollak wrote:
>
>>
>>
>> On Tue, Sep 23, 2008 at 7:26 AM, Oliver Lambert <[EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>> wrote:
>>
>>
>> On 23/09/2008, at 9:47 PM, David Pollak wrote:
>>
>>>
>>>
>>> On Tue, Sep 23, 2008 at 4:29 AM, Oliver Lambert
>>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>>>
>>> I don't understand some of what I see with the
>>> validation logic.
>>>
>>>
>>>> Right now, this is the way it works with the exception
>>>> of the client validation part.
>>>>
>>>> An example is MappedEmail (forget for a moment that
>>>> it's mapped to the DB):
>>>>
>>>> class MappedEmail[T<:Mapper[T]](owner: T, maxLen:
>>>> Int) extends MappedString[T](owner, maxLen) {
>>>>
>>>> override def setFilter = notNull _ :: toLower _
>>>> :: trim _ :: super.setFilter
>>>>
>>> Is notNull a validation rather than filter?
>>>
>>>
>>> notNull is a filter. The code looks more or less like:
>>>
>>> def notNull(in: String): String = if (in eq null) "" else in
>>>
>>>
>>> These filters will take " [EMAIL PROTECTED]
>>> <mailto:[EMAIL PROTECTED]> " and turn it into "[EMAIL PROTECTED]
>>> <mailto:[EMAIL PROTECTED]>"
>>>
>>>
>>>
>>>>
>>>> override def validations =
>>>> valRegex("^[a-z0-9._%-]+@(?:[a-z0-9-]+\\.)+[a-z]{2,4}$"
>>>> <mailto:[EMAIL
>>>> PROTECTED]:%5Ba-z0-9-%5D+%5C%5C.%29+%5Ba-z%5D%7B2,4%7D$>,
>>>> ??("Invalid email address") _ ::
>>>> super.validations
>>>>
>>> There are standard validations that apply to many fields
>>> (e.g notNull). Should these have a standard error
>>> message that is overridable with another on demand
>>>
>>>
>>> There are some standard validation functions in MappedString
>>> (notNull is a filter, not a validation). I did not preload
>>> them with error messages because I think it's easy enough
>>> for a developer to specify the error message. But you can
>>> write your own validation function collection that works the
>>> way you want to.
>>>
>>>
>>> Do/should validations stop at the first error message on
>>> the field, at least by default
>>>
>>>
>>> No. All the problems with input should be flagged, except
>>> in some extraordinary circumstance. If you want to do more
>>> complex validation logic, you can override validate which,
>>> by default, just interates through the existing validations.
>>
>> You have a message that the user is required to enter a field
>> that has been left null. Why bother doing any more validation
>> on the field. Why would you tell them its an invalid email
>> address as well
>>
>>
>> In the instant case, the single regular expression will cover
>> *all* of the validation cases.
>>
>> Please stop thinking of notNull as a validation function. It is
>> not. It is a filter that modifies the input to turn a 'null'
>> into an empty String. It's applied to programmatic setting of
>> the field and it's unlikely to be triggered by using input from a
>> form.
>
> No, I cant stop thinking this way until Im hit over the head
> repeatedly. The user has hit the "Save", or whatever, and has left
> out a mandatory email field. Why tell them its an "Invalid email
> address"
> when they never entered anything. That will confuse the poor
> buggers - they need to be told to enter the field.
>
>>
>>
>> If you need complex logic for validation, that's possible with
>> the existing mechanism, you just have to put the complex logic
>> into a validation function rather than chaining validations
>> together. On a broader note, it depends on how you present the
>> site to users. I personally dislike sites that do something like
>> "you didn't enter a long enough name"... okay I fix that and then
>> I get "there are illegal characters in your name." I'd rather
>> get both messages so I can fix both problems at once.
>
> Yup, I agree with you on that, but I have a counter. The user has
> entered a password and confirmed the password. You tell them that
> the password is not long enough. You also tell them - "oh yeah, by
> the way, the passwords don't match". Even without the "oh yeah..."
> they might think your trying to be a bit too smart. They are going
> to have to change the passwords anyway, so maybe next time they
> will match.
>
>>>>
>>>> }
>>>>
>>>>
>>>> setFilter: List[String => String]
>>>> validations: List[String => List[ValidationIssue]]
>>>>
>>>> Note the "setFilter" This is applied to both setting
>>>> the field and for any queries related to the field.
>>>> This means that the rules for transformation are well
>>>> known and visible to other parts of the application.
>>>> The same for the validations.
>>>>
>>> The filter is for the form to the mapped field. Why
>>> should queries (or anything) need to know this
>>> transformation.
>>> Isn't there a corresponding filter from the mapped field
>>> to the form (e.g null -> "")
>>>
>>>
>>> It's not a filter, but there is a toForm method on each
>>> MappedField which does the translation of the field into an
>>> XHTML form.
>>>
>>>
>>>
>>>> This keeps the validation (and mutation-on-set) logic
>>>> with the field.
>>>>
>>> Single field validations are being talked about, but
>>> what about validations that cover multiple fields -
>>> should a validator framework handle both?
>>>
>>>
>>> They do. First, the field-level validators can access other
>>> fields in the record.
>>>
>>>
>>> What about simple multiple field
>>> validations like dates (day month year) - should these
>>> be handled as a special case?
>>>
>>>
>>> Why? They fit right into the existing mechanism.
>>>
>> You respond as though the existing validation mechanism is
>> sufficient (and documented).
>>
>>
>> With the exception of the client-side validation being unified, I
>> have not heard a single use case for validation that is not
>> handled by the existing mechanism. If you've got a use case that
>> isn't being handled, please let me know. So, yes, after building
>> 30+ commercial web sites over the last 12 years and developing 3
>> major web frameworks, I am pretty confident that the existing
>> mechanism covers validation for every project I've worked on.
>>
> Good
>
>> On a broader note, it's clear that Lift lacks documentation.
>> There are a number of us who are huddled working on a plan for
>> documentation, but like everything else, commitments are required
>> in order to turn a project from a desire into reality. In the
>> mean time, the best that the Lift committers and others in the
>> community can do is answer questions and explain design decisions.
>>
> From what I have read in various threads, others (not just me)
> have been discussing validation without understanding what Lift
> has in place.
>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>> --
>> Lift, the simply functional web framework http://liftweb.net
>> Collaborative Task Management http://much4.us
>> Follow me: http://twitter.com/dpp
>> Git some: http://github.com/dpp
>>
>>
>>
>
>
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
