Charles F. Munat wrote:
> Sorry, Tim, I wasn't clear. I wasn't arguing for validation to be
> specified in the persistence layer. I was just saying that using
> annotations -- as JPA allows -- is nice. And it would be nice to do them
> in the model, where the validation is right next to the thing it validates.
>
> Also, I meant that validation should ideally happen on the client end
> before a trip to the server, hence with JS, but that one still needs to
> validate input at the server end to ensure good data and in case the
> user has JS turned off (or an old browser or something). It should fall
> back on server-side validation gracefully. Ideally.
>
> But this is probably what's already underway.
>
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
override def validations =
valRegex("^[a-z0-9._%-]+@(?:[a-z0-9-]+\\.)+[a-z]{2,4}$", ??("Invalid
email address") _ ::
super.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.
This keeps the validation (and mutation-on-set) logic with the field.
Thanks,
David
> Chas.
>
> Tim Perrett wrote:
>
>>> I'm sure you already thought of this, but it would be nice to be able to
>>> put the constraints in once and have the code generate both validation
>>> in the persistence layer and client-side JavaScript validation code in
>>> the forms, so the latter degrades gracefully to the former.
>>>
>>> Also, I note that JPA appears to allow validation to be inserted via
>>> annotation. That seems like a very nice way to do things -- just
>>> annotate the field when it's created to indicate the limitations on it.
>>>
>> Id say that validation in the persistence tier was probably not the
>> best way to do it. There is merit in having validation on entity
>> objects, but I think thats not what were aiming for here. The goal is
>> to create a flexible system that validation is a component of, and
>> therefore a lot more decoupled than persistence entity annotations
>> allow for.
>>
>> Validation does seem to be something people are crying out for right
>> now however.... but I agree with you that progressive enhancement
>> would be a good strategy and one that i would personally welcome with
>> open arms :-)
>>
>> Cheers
>>
>> Tim
>>
>>
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
