On 24/09/2008, at 1:00 AM, David Pollak wrote:
>
>
> On Tue, Sep 23, 2008 at 7:26 AM, Oliver Lambert <[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]>
>> 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] " and turn it into "[EMAIL
>> PROTECTED]
>> "
>>
>>
>>>
>>> override def validations = valRegex("^[a-z0-9._%-]+@(?:[a-z0-9-]+
>>> \\.)+[a-z]{2,4}$", ??("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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---
