I agree. I think we should be able to come up with something that is simply another layer in the flow, rather than tying it directly to a persistence layer. Like David said, most of mapper is not directly involved with JDBC, so we should be able to leverage a lot of what's in there to make something a little more backend-agnostic. I'd be happy to help with the JPA adapter when it gets to that point.
Derek On Mon, Sep 22, 2008 at 3:54 PM, Tim Perrett <[EMAIL PROTECTED]> 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 -~----------~----~----~----~------~----~------~--~---
