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.
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.
>
>> }
>>
>>
>> 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.
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.
>
>
>
>>
>
>
>
>
>
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
