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(...
Derek
On Tue, Sep 23, 2008 at 9:41 AM, Oliver Lambert <[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]> 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}$"<[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 [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
-~----------~----~----~----~------~----~------~--~---
