I don't understand some of what I see with the validation logic.
On 23/09/2008, at 9:14 AM, David Pollak wrote:
>
>
> 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
Is notNull a validation rather than filter?
>
> 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
Do/should validations stop at the first error message on the field, at
least by default
>
> }
>
> 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 -> "")
> 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? What about simple multiple field
validations like dates (day month year) - should these be handled as a
special case?
> 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 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
-~----------~----~----~----~------~----~------~--~---
