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