On Mon, Sep 22, 2008 at 9:51 PM, Derek Chen-Becker <[EMAIL PROTECTED]>wrote:
> I like the idea of composing lists of filters and validations for fields.
> Perhaps I'm being naive, but would it make sense to have corresponding
> validation "components" that can both do the server-side validation as well
> as spitting out proper javascript for client-side?
>
Yes. If you just have a function, the validation will be done server-side
only, but if you have a "Function with ClientValidation" then the
ClientValidation part can be called to generate client-side validation code.
> It seems like it should be simple for basic cases but I'm not sure how well
> it would work with more complex interactions. Ideally, the validation system
> would not only be able to handle simple things like format checking, date
> parsing/checking, etc, but also multiple field validations (i.e. endDate >
> startDate).
>
This is the value of having the fields know about the larger structure that
they live in. It is possible to have fields access other fields (client or
server) because there is a richer set of information available at the field
level.
>
>
> Derek
>
>
> On Mon, Sep 22, 2008 at 5:14 PM, David Pollak <[EMAIL PROTECTED]> 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
>> 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
>> }
>>
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
