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