[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Oliver Lambert]

Hey Chas,

No worries, I re-read too and understood the tone of your reply.
I'm playing devils advocate on validation to try to get a flexible
framework for everyone to use.

Ol
On 24/09/2008, at 4:07 PM, Charles F. Munat wrote:

>
> Charles F. Munat wrote:
>>> Running Ajax calls between fields for validation is pretty ugly,
>>> javascript validation would be better
>>
>> That's what I said.
>
> Sorry, Oliver. On re-reading, that sounds a little snippy, but I  
> didn't
> mean it that way. I just meant that we agree -- after mentioning it  
> as a
> possibility, I said it would be unnecessary since JavaScript would  
> have
> to be working anyway.
>
> Chas.
>
> >


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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Charles F. Munat]

Charles F. Munat wrote:
>> Running Ajax calls between fields for validation is pretty ugly, 
>> javascript validation would be better
> 
> That's what I said.

Sorry, Oliver. On re-reading, that sounds a little snippy, but I didn't 
mean it that way. I just meant that we agree -- after mentioning it as a 
possibility, I said it would be unnecessary since JavaScript would have 
to be working anyway.

Chas.

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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Charles F. Munat]

Oliver wrote:
> I like them to be validated as well, and to short circuit the remainder 
> of the field validation.

Feel free to set your validation up that way. Personally, I'd like my 
validation code to be smart enough to note when two non-redundant 
validation problems occur and to mention both, but to stop at the first 
when they are redundant.

For example, a field that is blank should not also trigger a "too short" 
error message, but a field that is both too short and contains 
prohibited characters should trigger both error messages.

But as I said, the best way is to provide immediate feedback on any 
field to indicate when it fails to meet validation *as the user enters 
data*, changing to positive indications when the validation rules are met.

> Preventing input of letters rather than digits will introduce some 
> pretty nasty and fragile javascript




   



   



Have yet to find a modern browser in which this didn't work. And this 
code can be easily adapted to prevent any specific ANSI characters from 
being entered, so you could, for example, have a field that allows only 
hexadecimal numbers.

> Audible indications could get annoying

Indeed. But my point was only that visual indications are not the limit. 
Not everyone can see.

> Running Ajax calls between fields for validation is pretty ugly, 
> javascript validation would be better

That's what I said.

Chas.

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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Oliver]

On Wed, Sep 24, 2008 at 5:35 AM, Charles F. Munat <[EMAIL PROTECTED]> wrote:

>
> Oliver Lambert wrote:
> > Do/should validations stop at the first error message on the field, at
> > least by default?
>
> I much prefer that they do not. It really irritates me when I'm using an
> online form and it tells me that something is invalid, then I fix it,
> resubmit, and get a new error.
>
> I'd much rather get a list of errors at the top of the form with the
> fields in error highlighted, or highlighted fields with the error
> messages either displayed at the field or as a mouseover popup (probably
> the former).
>
> In fact, ideally I like my forms to:
>
> 1) indicate which fields are required and which are optional,
>

I like them to be validated as well, and to short circuit the remainder of
the field validation.


> 2) give an example, when useful, of expected input (or the validation
> rule, such as "must be greater than 100"),
>
> 3) either prevent invalid input completely (e.g. preventing input of
> letters to a field that takes digits), or provide some sort of
> visual/audible indication of when the validation rule has been
> satisfied, such as a password field that indicates password strength and
> the minimum required, or a zip code field that indicates when the zip
> code entered matches the RegEx used to validate it.


Preventing input of letters rather than digits will introduce some pretty
nasty and fragile javascript
Audible indications could get annoying


> And, of course, I want the back end to validate as a fallback and to
> generate enough error output to permit the form to do 1-3 above. With
> AJAX, the form could actually validate using the back end as you tab
> from field to field (although if AJAX is working, so is JavaScript, so
> that's probably unnecessary).


Running Ajax calls between fields for validation is pretty ugly, javascript
validation would be better


>
> Having spent a lot of time in the past working with the W3C's Web
> Accessibility Initiative (WAI), I tend to be attentive to accessibility
> concerns and try to design all my sites to be usable and accessible to
> persons with disabilities -- visual, cognitive, motor, etc. Forms are
> always tricky for persons with disabilities.
>
> Chas.
>
> >
>

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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Charles F. Munat]

http://liftweb.net/index.php/RequirementsForForms

David Pollak wrote:
> 
> 
> Charles F. Munat wrote:
>> Oliver Lambert wrote:
>>   
>>> Do/should validations stop at the first error message on the field, at 
>>> least by default?
>>> 
>>
>> I much prefer that they do not. It really irritates me when I'm using an 
>> online form and it tells me that something is invalid, then I fix it, 
>> resubmit, and get a new error.
>>
>> I'd much rather get a list of errors at the top of the form with the 
>> fields in error highlighted, or highlighted fields with the error 
>> messages either displayed at the field or as a mouseover popup (probably 
>> the former).
>>
>> In fact, ideally I like my forms to:
>>
>> 1) indicate which fields are required and which are optional,
>>
>> 2) give an example, when useful, of expected input (or the validation 
>> rule, such as "must be greater than 100"),
>>
>> 3) either prevent invalid input completely (e.g. preventing input of 
>> letters to a field that takes digits), or provide some sort of 
>> visual/audible indication of when the validation rule has been 
>> satisfied, such as a password field that indicates password strength and 
>> the minimum required, or a zip code field that indicates when the zip 
>> code entered matches the RegEx used to validate it.
>>   
> I totally agree with this set of requirements.  Thanks for being clear 
> about them.  Care to put up a wiki page with "input form requirements" 
> and include this?
> 
> 
>> And, of course, I want the back end to validate as a fallback and to 
>> generate enough error output to permit the form to do 1-3 above. With 
>> AJAX, the form could actually validate using the back end as you tab 
>> from field to field (although if AJAX is working, so is JavaScript, so 
>> that's probably unnecessary).
>>
>> Having spent a lot of time in the past working with the W3C's Web 
>> Accessibility Initiative (WAI), I tend to be attentive to accessibility 
>> concerns and try to design all my sites to be usable and accessible to 
>> persons with disabilities -- visual, cognitive, motor, etc. Forms are 
>> always tricky for persons with disabilities.
>>
>> Chas.
>>
>>
>>   
> 
> > 

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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[David Pollak]

Charles F. Munat wrote:
> Oliver Lambert wrote:
>   
>> Do/should validations stop at the first error message on the field, at 
>> least by default?
>> 
>
> I much prefer that they do not. It really irritates me when I'm using an 
> online form and it tells me that something is invalid, then I fix it, 
> resubmit, and get a new error.
>
> I'd much rather get a list of errors at the top of the form with the 
> fields in error highlighted, or highlighted fields with the error 
> messages either displayed at the field or as a mouseover popup (probably 
> the former).
>
> In fact, ideally I like my forms to:
>
> 1) indicate which fields are required and which are optional,
>
> 2) give an example, when useful, of expected input (or the validation 
> rule, such as "must be greater than 100"),
>
> 3) either prevent invalid input completely (e.g. preventing input of 
> letters to a field that takes digits), or provide some sort of 
> visual/audible indication of when the validation rule has been 
> satisfied, such as a password field that indicates password strength and 
> the minimum required, or a zip code field that indicates when the zip 
> code entered matches the RegEx used to validate it.
>   
I totally agree with this set of requirements.  Thanks for being clear 
about them.  Care to put up a wiki page with "input form requirements" 
and include this?


> And, of course, I want the back end to validate as a fallback and to 
> generate enough error output to permit the form to do 1-3 above. With 
> AJAX, the form could actually validate using the back end as you tab 
> from field to field (although if AJAX is working, so is JavaScript, so 
> that's probably unnecessary).
>
> Having spent a lot of time in the past working with the W3C's Web 
> Accessibility Initiative (WAI), I tend to be attentive to accessibility 
> concerns and try to design all my sites to be usable and accessible to 
> persons with disabilities -- visual, cognitive, motor, etc. Forms are 
> always tricky for persons with disabilities.
>
> Chas.
>
> >
>   

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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[David Pollak]

Derek Chen-Becker wrote:
> If you want to tell them to enter a value, I'm sure that you could 
> write (if it doesn't already exist) a notEmpty validation that would 
> say the right thing and do something like:
>
> val validations = notEmpty("You must provide an email address") _ :: 
> valRegex(...

Or, you could use PartialFunctions so that you could write:

validations = notEmpty(...) orElse valRegex(..) :: super.validations

The general idea of lists of validators works.  Using Scala's facilities 
rather than inventing complex structures means that your validation code 
will read like much of your other code.

Thanks,

David

>
> Derek
>
> On Tue, Sep 23, 2008 at 9:41 AM, Oliver Lambert <[EMAIL PROTECTED] 
> > wrote:
>
>
> On 24/09/2008, at 1:00 AM, David Pollak wrote:
>
>>
>>
>> On Tue, Sep 23, 2008 at 7:26 AM, Oliver Lambert <[EMAIL PROTECTED]
>> > wrote:
>>
>>
>> On 23/09/2008, at 9:47 PM, David Pollak wrote:
>>
>>>
>>>
>>> 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}$"
 ,
 ??("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.
>>
>> You have a message that the user is required to enter a field
>> that has been left null. Why bother doing any more validation
>> on the field. Why would you tell them its an invalid email
>> address as well
>>
>>
>> In the instant case, the single regular expression will cover
>> *all* of the validation cases.
>>
>> Please stop thinking of notNull as a validation function.  It is
>> not.  It is a filter that modifies the input to turn a 'null'
>> into an empty String.  It's applied to programmatic setting of
>> the field and it's unlikely to be triggered by using input from a
>> form.
>
> No, I cant stop thinking this way until Im hit over the head
> repeatedly. The user has hit the "Save", or whatever, and has left
> out a mandatory email field. Why tell them its an "Invalid email
> address"
> when they never entered anything. That will confuse the poor
> buggers - they need to be told to enter the field.
>
>>
>>
>> If you need complex logic for validation, that's possible with
>> the existing mechanism, you just have to put the complex logic
>> into a validation function rather than chaining validations
>> together.  On a broader note, it depends on how you present the
>> site to users.  I personally dislike sites that do something like
>> "you didn't enter a long enough name"... okay I fi

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Derek Chen-Becker]

I agree. Currently I do something like that in my own code (really looking
forward to replacing it thought :) ):

  def validMember_? = {
val errorChecks =
  (if (member.userId == "") { S.error("You must provide a user Id");
false } else true) ::
  (if (member.userId.length < 6) { S.error("User Id must be at least 6
characters"); false } else true ) ::
  (if (member.givenName == "") { S.error("You must provide a first
name"); false } else true ) ::
  (if (member.surname == "") { S.error("You must provide a last name");
false } else true ) ::
  (if (member.birthdate == null) { S.error("Invalid birthday"); false }
else true ) ::
  (if (member.email == "") { S.error("You must provide an email
address"); false } else true ) :: Nil

errorChecks forall(_ == true)
  }

The trick is to order them so that that the messages make sense in context.
Note my two checks on member.userId...

Derek

On Tue, Sep 23, 2008 at 1:35 PM, Charles F. Munat <[EMAIL PROTECTED]> wrote:

>
> Oliver Lambert wrote:
> > Do/should validations stop at the first error message on the field, at
> > least by default?
>
> I much prefer that they do not. It really irritates me when I'm using an
> online form and it tells me that something is invalid, then I fix it,
> resubmit, and get a new error.
>
> I'd much rather get a list of errors at the top of the form with the
> fields in error highlighted, or highlighted fields with the error
> messages either displayed at the field or as a mouseover popup (probably
> the former).
>
> In fact, ideally I like my forms to:
>
> 1) indicate which fields are required and which are optional,
>
> 2) give an example, when useful, of expected input (or the validation
> rule, such as "must be greater than 100"),
>
> 3) either prevent invalid input completely (e.g. preventing input of
> letters to a field that takes digits), or provide some sort of
> visual/audible indication of when the validation rule has been
> satisfied, such as a password field that indicates password strength and
> the minimum required, or a zip code field that indicates when the zip
> code entered matches the RegEx used to validate it.
>
> And, of course, I want the back end to validate as a fallback and to
> generate enough error output to permit the form to do 1-3 above. With
> AJAX, the form could actually validate using the back end as you tab
> from field to field (although if AJAX is working, so is JavaScript, so
> that's probably unnecessary).
>
> Having spent a lot of time in the past working with the W3C's Web
> Accessibility Initiative (WAI), I tend to be attentive to accessibility
> concerns and try to design all my sites to be usable and accessible to
> persons with disabilities -- visual, cognitive, motor, etc. Forms are
> always tricky for persons with disabilities.
>
> Chas.
>
> >
>

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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Charles F. Munat]

Oliver Lambert wrote:
> Do/should validations stop at the first error message on the field, at 
> least by default?

I much prefer that they do not. It really irritates me when I'm using an 
online form and it tells me that something is invalid, then I fix it, 
resubmit, and get a new error.

I'd much rather get a list of errors at the top of the form with the 
fields in error highlighted, or highlighted fields with the error 
messages either displayed at the field or as a mouseover popup (probably 
the former).

In fact, ideally I like my forms to:

1) indicate which fields are required and which are optional,

2) give an example, when useful, of expected input (or the validation 
rule, such as "must be greater than 100"),

3) either prevent invalid input completely (e.g. preventing input of 
letters to a field that takes digits), or provide some sort of 
visual/audible indication of when the validation rule has been 
satisfied, such as a password field that indicates password strength and 
the minimum required, or a zip code field that indicates when the zip 
code entered matches the RegEx used to validate it.

And, of course, I want the back end to validate as a fallback and to 
generate enough error output to permit the form to do 1-3 above. With 
AJAX, the form could actually validate using the back end as you tab 
from field to field (although if AJAX is working, so is JavaScript, so 
that's probably unnecessary).

Having spent a lot of time in the past working with the W3C's Web 
Accessibility Initiative (WAI), I tend to be attentive to accessibility 
concerns and try to design all my sites to be usable and accessible to 
persons with disabilities -- visual, cognitive, motor, etc. Forms are 
always tricky for persons with disabilities.

Chas.

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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Derek Chen-Becker]

If you want to tell them to enter a value, I'm sure that you could write (if
it doesn't already exist) a notEmpty validation that would say the right
thing and do something like:

val validations = notEmpty("You must provide an email address") _ ::
valRegex(...

Derek

On Tue, Sep 23, 2008 at 9:41 AM, Oliver Lambert <[EMAIL PROTECTED]> wrote:

>
> On 24/09/2008, at 1:00 AM, David Pollak wrote:
>
>
>
> On Tue, Sep 23, 2008 at 7:26 AM, Oliver Lambert <[EMAIL PROTECTED]> wrote:
>
>>
>> On 23/09/2008, at 9:47 PM, David Pollak wrote:
>>
>>
>>
>> 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.
>>
>>
>> You have a message that the user is required to enter a field that has
>> been left null. Why bother doing any more validation on the field. Why would
>> you tell them its an invalid email address as well
>>
>
> In the instant case, the single regular expression will cover *all* of the
> validation cases.
>
> Please stop thinking of notNull as a validation function.  It is not.  It
> is a filter that modifies the input to turn a 'null' into an empty String.
> It's applied to programmatic setting of the field and it's unlikely to be
> triggered by using input from a form.
>
>
> No, I cant stop thinking this way until Im hit over the head repeatedly.
> The user has hit the "Save", or whatever, and has left out a mandatory email
> field. Why tell them its an "Invalid email address"
> when they never entered anything. That will confuse the poor buggers - they
> need to be told to enter the field.
>
>
>
> If you need complex logic for validation, that's possible with the existing
> mechanism, you just have to put the complex logic into a validation function
> rather than chaining validations together.  On a broader note, it depends on
> how you present the site to users.  I personally dislike sites that do
> something like "you didn't enter a long enough name"... okay I fix that and
> then I get "there are illegal characters in your name."  I'd rather get both
> messages so I can fix both problems at once.
>
>
> Yup, I agree with you on that, but I have a counter. The user has entered a
> password and confirmed the password. You tell them that the password is not
> long enough. You also tell them - "oh yeah, by the way, the passwords don't
> match". Even without the "oh yeah..." they might think your trying to be a
> bit too smart. They are going to have to change the passwords anyway, so
> maybe next time they will match.
>
>
>>> }
>>>
>>>
>>> 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 i

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Oliver Lambert]

On 24/09/2008, at 1:00 AM, David Pollak wrote:

>
>
> On Tue, Sep 23, 2008 at 7:26 AM, Oliver Lambert <[EMAIL PROTECTED]>  
> wrote:
>
> On 23/09/2008, at 9:47 PM, David Pollak wrote:
>
>>
>>
>> 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}$", ??("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.
>
> You have a message that the user is required to enter a field that  
> has been left null. Why bother doing any more validation on the  
> field. Why would you tell them its an invalid email address as well
>
> In the instant case, the single regular expression will cover *all*  
> of the validation cases.
>
> Please stop thinking of notNull as a validation function.  It is  
> not.  It is a filter that modifies the input to turn a 'null' into  
> an empty String.  It's applied to programmatic setting of the field  
> and it's unlikely to be triggered by using input from a form.

No, I cant stop thinking this way until Im hit over the head  
repeatedly. The user has hit the "Save", or whatever, and has left out  
a mandatory email field. Why tell them its an "Invalid email address"
when they never entered anything. That will confuse the poor buggers -  
they need to be told to enter the field.

>
>
> If you need complex logic for validation, that's possible with the  
> existing mechanism, you just have to put the complex logic into a  
> validation function rather than chaining validations together.  On a  
> broader note, it depends on how you present the site to users.  I  
> personally dislike sites that do something like "you didn't enter a  
> long enough name"... okay I fix that and then I get "there are  
> illegal characters in your name."  I'd rather get both messages so I  
> can fix both problems at once.

Yup, I agree with you on that, but I have a counter. The user has  
entered a password and confirmed the password. You tell them that the  
password is not long enough. You also tell them - "oh yeah, by the  
way, the passwords don't match". Even without the "oh yeah..." they  
might think your trying to be a bit too smart. They are going to have  
to change the passwords anyway, so maybe next time they will match.
>>>
>>> }
>>>
>>> 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 acc

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[David Pollak]

On Tue, Sep 23, 2008 at 7:26 AM, Oliver Lambert <[EMAIL PROTECTED]> wrote:

>
> On 23/09/2008, at 9:47 PM, David Pollak wrote:
>
>
>
> 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.
>
>
> You have a message that the user is required to enter a field that has been
> left null. Why bother doing any more validation on the field. Why would you
> tell them its an invalid email address as well
>

In the instant case, the single regular expression will cover *all* of the
validation cases.

Please stop thinking of notNull as a validation function.  It is not.  It is
a filter that modifies the input to turn a 'null' into an empty String.
It's applied to programmatic setting of the field and it's unlikely to be
triggered by using input from a form.

If you need complex logic for validation, that's possible with the existing
mechanism, you just have to put the complex logic into a validation function
rather than chaining validations together.  On a broader note, it depends on
how you present the site to users.  I personally dislike sites that do
something like "you didn't enter a long enough name"... okay I fix that and
then I get "there are illegal characters in your name."  I'd rather get both
messages so I can fix both problems at once.


>
>> }
>>
>>
>> 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 respond as though the existing validation mechanism is sufficient (and
> documented).
>

With the exception of the client-side validation being unified, I have not
heard a single use case for validation that is not handled by the existing
mechanism.  If you've got a use case that isn't being handled, please let me
know.  So, yes, after building 30+ commercial web sites over the last 12
years and developing 3 major web frameworks, I am pretty confident that the
existing mechanism covers validation for every project I've worked on.

On a broader note, it's clear that Lift lacks documentation.  There are a
number of us who are huddled working o

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Oliver Lambert]

On 23/09/2008, at 9:47 PM, David Pollak wrote:

>
>
> 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}$", ??("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.

You have a message that the user is required to enter a field that has  
been left null. Why bother doing any more validation on the field. Why  
would you tell them its an invalid email address as well
>
>>
>> }
>>
>> 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 respond as though the existing validation mechanism is sufficient  
(and documented).

>
>
>
> >


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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Marius]

No issue Dave ... at least not for me. I was just that this "pattern"
of doing things may lead to certain confusions to some people ...
besides that in a declaration like:

class MyRecord extends Record[MyRecord] {
...
}

there is some sort of redundant information as 'MyRecord' appears
twice. Of course this is just a simple example.

So my only question was that with this way of doing things which in
some extents it brings more complexity (in the declarations) was
bringing enough benefits and wont scare people away. That's it.


P.S.
I might have too much cofee though :)

Br's,
Marius

On Sep 23, 3:42 pm, David Pollak <[EMAIL PROTECTED]> wrote:
> Marius wrote:
> > I'm fully aware of that ... I was just wondering if there were other
> > rationales behind this approach ...
>
> > or we can have
>
> > trait Foo[T <: Foo[T]]) {
> >   self: T =>
> >   def dog(t: T) = t.doSomething
>
> >   def doSomething
>
> > }
>
> Sorry for being clueless... but I'm not sure what the question/issue
> is... maybe it's just that I haven't had coffee yet and I'm going slow
> this morning. :-(
>
> > Br's,
> > Marius
>
> > On Sep 23, 3:07 pm, "David Pollak" <[EMAIL PROTECTED]>
> > wrote:
>
> >> On Tue, Sep 23, 2008 at 5:03 AM, Marius <[EMAIL PROTECTED]> wrote:
>
> >>> Thoughts/comments on this?
>
> >>> Br's,
> >>> Marius
>
> >>> On Sep 22, 11:23 pm, Marius <[EMAIL PROTECTED]> wrote:
>
>  one clarification .. by "by which the only benefit that I see is that
>  *this* and MyType are actually of the same type sometimes leading to
>  ease of writing expressions" are really meant that *this* and a that :
>  MyType having the same type can give certain clarity of the
>  expression. Just like SLS example 5.3.5
>
> >> Actually, specifying the self-type makes the following code work correctly
>
> >> trait Foo[T <: Foo[T]]) {
> >>   def dog: T
>
> >> }
>
> >> Without the self-type, T is not a subclass of Foo.  But:
>
> >> trait Foo[T <: Foo[T]]) {
> >>   self: T =>
> >>   def dog: T
>
> >> }
>
> >> The compiler knows that T is a subclass of Foo.
>
>  Br's,
>  Marius
>
>  On Sep 22, 11:14 pm, Marius <[EMAIL PROTECTED]> wrote:
>
> > I'll do some noodling on this  ... starting first with understanding
> > of the design intent (which I assume it is founded on *ease of use*)
>
> > I see that Record follows the same parametrization paradigm ...
>
> > trait Record[MyType <: Record[MyType]] {
> >   self: MyType =>
>
> > ...
>
> > }
>
> > or
>
> > trait MetaRecord[BaseRecord <: Record[BaseRecord]] { self: BaseRecord
> > =>
> > ...
>
> > }
>
> > by which the only benefit that I see is that *this* and MyType are
> > actually of the same type sometimes leading to ease of writing
> > expressions. Is there another benefit?
>
> > The non benefit is that user needs to type somehow redundant stuff.
>
> > class MyRecord extends Record[MyRecord] {
>
> > ...
>
> > }
>
> > or
>
> > class MyMetaRecord[Rec <: MyRecord[MyMetaRecord]] extends
> > MetaRecord[Rec] {
>
> > ...
>
> > }
>
> > ... see I already typed MyRecord/Rec twice leading to a certain
> > redundancy. To me it is not really a drawback ... but I need to
> > understand if this paradigm is buying us a whole lot.
>
> > Br's,
> > Marius
>
> > On Sep 22, 9:05 pm, "David Pollak" <[EMAIL PROTECTED]>
> > wrote:
>
> >> Folks,
>
> >> For those who want to help, but are not yet Lift committers, please
>
> >>> contact
>
> >> me off-list and let's chat about you contributing to this project.
>
> >> If you're a committer, please look at the the wip-record2-dpp branch.
>
> >>>  What
>
> >> I've been doing to start is to try to decompose the Mapper and
>
> >>> Mapped*
>
> >> classes in Lift into composable traits in the net.liftweb.record
>
> >>> package.
>
> >> Once we have a reasonable set of components we could compose
>
> >>> together, then
>
> >> we can start filling in the pieces.
>
> >> So... step 1, finish the decomposition of the Mapped* stuff into the
>
> >>> Record
>
> >> stuff.  Clean up the stuff that doesn't make sense (e.g.,
>
> >>> getSingleton ->
>
> >> meta... although this is on Mapper, but you get the idea).  How do we
> >> convert the field to/from String, XML, HTML Form, etc.?  What are the
> >> validation rules?  What are the access control rules (yes, this is
>
> >>> already
>
> >> built into Lift's Mapper stuff)?
>
> >> Step 2, decompose the Mapper and MetaMapper stuff in the same way...
>
> >>> what's
>
> >> necesssary to map to/from XML, HTML forms, different storage
>
> >>> mechanisms etc.
>
> >> Step 3, fill in the core functionality... copy and paste whatever
>
> >>> valuable
>
> >> code there is from Mapper (note than only about 20% of mapper is JDBC
> >> related).
>
> >> Step 4, build an abstraction layer for JPA so you can compose a JPA
> >> persis

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[David Pollak]

Marius wrote:
> I'm fully aware of that ... I was just wondering if there were other
> rationales behind this approach ...
>
> or we can have
>
> trait Foo[T <: Foo[T]]) {
>   self: T =>
>   def dog(t: T) = t.doSomething
>
>   def doSomething
>
> }
>   
Sorry for being clueless... but I'm not sure what the question/issue 
is... maybe it's just that I haven't had coffee yet and I'm going slow 
this morning. :-(

> Br's,
> Marius
>
> On Sep 23, 3:07 pm, "David Pollak" <[EMAIL PROTECTED]>
> wrote:
>   
>> On Tue, Sep 23, 2008 at 5:03 AM, Marius <[EMAIL PROTECTED]> wrote:
>>
>> 
>>> Thoughts/comments on this?
>>>   
>>> Br's,
>>> Marius
>>>   
>>> On Sep 22, 11:23 pm, Marius <[EMAIL PROTECTED]> wrote:
>>>   
 one clarification .. by "by which the only benefit that I see is that
 *this* and MyType are actually of the same type sometimes leading to
 ease of writing expressions" are really meant that *this* and a that :
 MyType having the same type can give certain clarity of the
 expression. Just like SLS example 5.3.5
 
>> Actually, specifying the self-type makes the following code work correctly
>>
>> trait Foo[T <: Foo[T]]) {
>>   def dog: T
>>
>> }
>>
>> Without the self-type, T is not a subclass of Foo.  But:
>>
>> trait Foo[T <: Foo[T]]) {
>>   self: T =>
>>   def dog: T
>>
>> }
>>
>> The compiler knows that T is a subclass of Foo.
>>
>>
>>
>>
>>
>> 
 Br's,
 Marius
 
 On Sep 22, 11:14 pm, Marius <[EMAIL PROTECTED]> wrote:
 
> I'll do some noodling on this  ... starting first with understanding
> of the design intent (which I assume it is founded on *ease of use*)
>   
> I see that Record follows the same parametrization paradigm ...
>   
> trait Record[MyType <: Record[MyType]] {
>   self: MyType =>
>   
> ...
>   
> }
>   
> or
>   
> trait MetaRecord[BaseRecord <: Record[BaseRecord]] { self: BaseRecord
> =>
> ...
>   
> }
>   
> by which the only benefit that I see is that *this* and MyType are
> actually of the same type sometimes leading to ease of writing
> expressions. Is there another benefit?
>   
> The non benefit is that user needs to type somehow redundant stuff.
>   
> class MyRecord extends Record[MyRecord] {
>   
> ...
>   
> }
>   
> or
>   
> class MyMetaRecord[Rec <: MyRecord[MyMetaRecord]] extends
> MetaRecord[Rec] {
>   
> ...
>   
> }
>   
> ... see I already typed MyRecord/Rec twice leading to a certain
> redundancy. To me it is not really a drawback ... but I need to
> understand if this paradigm is buying us a whole lot.
>   
> Br's,
> Marius
>   
> On Sep 22, 9:05 pm, "David Pollak" <[EMAIL PROTECTED]>
> wrote:
>   
>> Folks,
>> 
>> For those who want to help, but are not yet Lift committers, please
>> 
>>> contact
>>>   
>> me off-list and let's chat about you contributing to this project.
>> 
>> If you're a committer, please look at the the wip-record2-dpp branch.
>> 
>>>  What
>>>   
>> I've been doing to start is to try to decompose the Mapper and
>> 
>>> Mapped*
>>>   
>> classes in Lift into composable traits in the net.liftweb.record
>> 
>>> package.
>>>   
>> Once we have a reasonable set of components we could compose
>> 
>>> together, then
>>>   
>> we can start filling in the pieces.
>> 
>> So... step 1, finish the decomposition of the Mapped* stuff into the
>> 
>>> Record
>>>   
>> stuff.  Clean up the stuff that doesn't make sense (e.g.,
>> 
>>> getSingleton ->
>>>   
>> meta... although this is on Mapper, but you get the idea).  How do we
>> convert the field to/from String, XML, HTML Form, etc.?  What are the
>> validation rules?  What are the access control rules (yes, this is
>> 
>>> already
>>>   
>> built into Lift's Mapper stuff)?
>> 
>> Step 2, decompose the Mapper and MetaMapper stuff in the same way...
>> 
>>> what's
>>>   
>> necesssary to map to/from XML, HTML forms, different storage
>> 
>>> mechanisms etc.
>>>   
>> Step 3, fill in the core functionality... copy and paste whatever
>> 
>>> valuable
>>>   
>> code there is from Mapper (note than only about 20% of mapper is JDBC
>> related).
>> 
>> Step 4, build an abstraction layer for JPA so you can compose a JPA
>> persisted Record just by mixing in the JPA adaptor... and the same
>>>

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Marius]

I'm fully aware of that ... I was just wondering if there were other
rationales behind this approach ...

or we can have

trait Foo[T <: Foo[T]]) {
  self: T =>
  def dog(t: T) = t.doSomething

  def doSomething

}
Br's,
Marius

On Sep 23, 3:07 pm, "David Pollak" <[EMAIL PROTECTED]>
wrote:
> On Tue, Sep 23, 2008 at 5:03 AM, Marius <[EMAIL PROTECTED]> wrote:
>
> > Thoughts/comments on this?
>
> > Br's,
> > Marius
>
> > On Sep 22, 11:23 pm, Marius <[EMAIL PROTECTED]> wrote:
> > > one clarification .. by "by which the only benefit that I see is that
> > > *this* and MyType are actually of the same type sometimes leading to
> > > ease of writing expressions" are really meant that *this* and a that :
> > > MyType having the same type can give certain clarity of the
> > > expression. Just like SLS example 5.3.5
>
> Actually, specifying the self-type makes the following code work correctly
>
> trait Foo[T <: Foo[T]]) {
>   def dog: T
>
> }
>
> Without the self-type, T is not a subclass of Foo.  But:
>
> trait Foo[T <: Foo[T]]) {
>   self: T =>
>   def dog: T
>
> }
>
> The compiler knows that T is a subclass of Foo.
>
>
>
>
>
> > > Br's,
> > > Marius
>
> > > On Sep 22, 11:14 pm, Marius <[EMAIL PROTECTED]> wrote:
>
> > > > I'll do some noodling on this  ... starting first with understanding
> > > > of the design intent (which I assume it is founded on *ease of use*)
>
> > > > I see that Record follows the same parametrization paradigm ...
>
> > > > trait Record[MyType <: Record[MyType]] {
> > > >   self: MyType =>
>
> > > > ...
>
> > > > }
>
> > > > or
>
> > > > trait MetaRecord[BaseRecord <: Record[BaseRecord]] { self: BaseRecord
> > > > =>
> > > > ...
>
> > > > }
>
> > > > by which the only benefit that I see is that *this* and MyType are
> > > > actually of the same type sometimes leading to ease of writing
> > > > expressions. Is there another benefit?
>
> > > > The non benefit is that user needs to type somehow redundant stuff.
>
> > > > class MyRecord extends Record[MyRecord] {
>
> > > > ...
>
> > > > }
>
> > > > or
>
> > > > class MyMetaRecord[Rec <: MyRecord[MyMetaRecord]] extends
> > > > MetaRecord[Rec] {
>
> > > > ...
>
> > > > }
>
> > > > ... see I already typed MyRecord/Rec twice leading to a certain
> > > > redundancy. To me it is not really a drawback ... but I need to
> > > > understand if this paradigm is buying us a whole lot.
>
> > > > Br's,
> > > > Marius
>
> > > > On Sep 22, 9:05 pm, "David Pollak" <[EMAIL PROTECTED]>
> > > > wrote:
>
> > > > > Folks,
>
> > > > > For those who want to help, but are not yet Lift committers, please
> > contact
> > > > > me off-list and let's chat about you contributing to this project.
>
> > > > > If you're a committer, please look at the the wip-record2-dpp branch.
> >  What
> > > > > I've been doing to start is to try to decompose the Mapper and
> > Mapped*
> > > > > classes in Lift into composable traits in the net.liftweb.record
> > package.
> > > > > Once we have a reasonable set of components we could compose
> > together, then
> > > > > we can start filling in the pieces.
>
> > > > > So... step 1, finish the decomposition of the Mapped* stuff into the
> > Record
> > > > > stuff.  Clean up the stuff that doesn't make sense (e.g.,
> > getSingleton ->
> > > > > meta... although this is on Mapper, but you get the idea).  How do we
> > > > > convert the field to/from String, XML, HTML Form, etc.?  What are the
> > > > > validation rules?  What are the access control rules (yes, this is
> > already
> > > > > built into Lift's Mapper stuff)?
>
> > > > > Step 2, decompose the Mapper and MetaMapper stuff in the same way...
> > what's
> > > > > necesssary to map to/from XML, HTML forms, different storage
> > mechanisms etc.
>
> > > > > Step 3, fill in the core functionality... copy and paste whatever
> > valuable
> > > > > code there is from Mapper (note than only about 20% of mapper is JDBC
> > > > > related).
>
> > > > > Step 4, build an abstraction layer for JPA so you can compose a JPA
> > > > > persisted Record just by mixing in the JPA adaptor... and the same
> > for the
> > > > > JDBC adaptor, etc.
>
> > > > > Step 5, write a translation guide from Mapper -> Record
>
> > > > > Questions?
>
> > > > > Thanks,
>
> > > > > David
>
> > > > > PS -- on the validation front, currently, Mapper fields have a
> > > > > List[Function[T, List[ValidationIssue]]] that is the access to the
> > > > > server-side validation rules.  There exist a bunch of functions on
> > > > > MappedString, etc. to do common validations (min len, max len, regex,
> > etc.)
> > > > > In order to get client-side validation, we can have a subclass of
> > Function
> > > > > that implements jsValidation: JsExp  That will be the cue to include
> > the
> > > > > client-side validation in the form as it's being composed.  Cool,
> > huh?
>
> > > > > On Mon, Sep 22, 2008 at 10:42 AM, Alex Cruise <[EMAIL PROTECTED]>
> > wrote:
>
> > > > > > David Pollak wrote:
> > > > > > > I think the stuff that marius h

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[David Pollak]

On Tue, Sep 23, 2008 at 5:03 AM, Marius <[EMAIL PROTECTED]> wrote:

>
> Thoughts/comments on this?
>
>
> Br's,
> Marius
>
> On Sep 22, 11:23 pm, Marius <[EMAIL PROTECTED]> wrote:
> > one clarification .. by "by which the only benefit that I see is that
> > *this* and MyType are actually of the same type sometimes leading to
> > ease of writing expressions" are really meant that *this* and a that :
> > MyType having the same type can give certain clarity of the
> > expression. Just like SLS example 5.3.5
>


Actually, specifying the self-type makes the following code work correctly

trait Foo[T <: Foo[T]]) {
  def dog: T
}

Without the self-type, T is not a subclass of Foo.  But:

trait Foo[T <: Foo[T]]) {
  self: T =>
  def dog: T
}

The compiler knows that T is a subclass of Foo.



> >
> > Br's,
> > Marius
> >
> > On Sep 22, 11:14 pm, Marius <[EMAIL PROTECTED]> wrote:
> >
> > > I'll do some noodling on this  ... starting first with understanding
> > > of the design intent (which I assume it is founded on *ease of use*)
> >
> > > I see that Record follows the same parametrization paradigm ...
> >
> > > trait Record[MyType <: Record[MyType]] {
> > >   self: MyType =>
> >
> > > ...
> >
> > > }
> >
> > > or
> >
> > > trait MetaRecord[BaseRecord <: Record[BaseRecord]] { self: BaseRecord
> > > =>
> > > ...
> >
> > > }
> >
> > > by which the only benefit that I see is that *this* and MyType are
> > > actually of the same type sometimes leading to ease of writing
> > > expressions. Is there another benefit?
> >
> > > The non benefit is that user needs to type somehow redundant stuff.
> >
> > > class MyRecord extends Record[MyRecord] {
> >
> > > ...
> >
> > > }
> >
> > > or
> >
> > > class MyMetaRecord[Rec <: MyRecord[MyMetaRecord]] extends
> > > MetaRecord[Rec] {
> >
> > > ...
> >
> > > }
> >
> > > ... see I already typed MyRecord/Rec twice leading to a certain
> > > redundancy. To me it is not really a drawback ... but I need to
> > > understand if this paradigm is buying us a whole lot.
> >
> > > Br's,
> > > Marius
> >
> > > On Sep 22, 9:05 pm, "David Pollak" <[EMAIL PROTECTED]>
> > > wrote:
> >
> > > > Folks,
> >
> > > > For those who want to help, but are not yet Lift committers, please
> contact
> > > > me off-list and let's chat about you contributing to this project.
> >
> > > > If you're a committer, please look at the the wip-record2-dpp branch.
>  What
> > > > I've been doing to start is to try to decompose the Mapper and
> Mapped*
> > > > classes in Lift into composable traits in the net.liftweb.record
> package.
> > > > Once we have a reasonable set of components we could compose
> together, then
> > > > we can start filling in the pieces.
> >
> > > > So... step 1, finish the decomposition of the Mapped* stuff into the
> Record
> > > > stuff.  Clean up the stuff that doesn't make sense (e.g.,
> getSingleton ->
> > > > meta... although this is on Mapper, but you get the idea).  How do we
> > > > convert the field to/from String, XML, HTML Form, etc.?  What are the
> > > > validation rules?  What are the access control rules (yes, this is
> already
> > > > built into Lift's Mapper stuff)?
> >
> > > > Step 2, decompose the Mapper and MetaMapper stuff in the same way...
> what's
> > > > necesssary to map to/from XML, HTML forms, different storage
> mechanisms etc.
> >
> > > > Step 3, fill in the core functionality... copy and paste whatever
> valuable
> > > > code there is from Mapper (note than only about 20% of mapper is JDBC
> > > > related).
> >
> > > > Step 4, build an abstraction layer for JPA so you can compose a JPA
> > > > persisted Record just by mixing in the JPA adaptor... and the same
> for the
> > > > JDBC adaptor, etc.
> >
> > > > Step 5, write a translation guide from Mapper -> Record
> >
> > > > Questions?
> >
> > > > Thanks,
> >
> > > > David
> >
> > > > PS -- on the validation front, currently, Mapper fields have a
> > > > List[Function[T, List[ValidationIssue]]] that is the access to the
> > > > server-side validation rules.  There exist a bunch of functions on
> > > > MappedString, etc. to do common validations (min len, max len, regex,
> etc.)
> > > > In order to get client-side validation, we can have a subclass of
> Function
> > > > that implements jsValidation: JsExp  That will be the cue to include
> the
> > > > client-side validation in the form as it's being composed.  Cool,
> huh?
> >
> > > > On Mon, Sep 22, 2008 at 10:42 AM, Alex Cruise <[EMAIL PROTECTED]>
> wrote:
> >
> > > > > David Pollak wrote:
> > > > > > I think the stuff that marius has done is interesting, but it is
> at
> > > > > > odds with the long promised record/field stuff.
> >
> > > > > > This morning, I figured out how to ask the right questions in
> order to
> > > > > > manage the record/field project. If I can get one or two
> volunteers, I
> > > > > > think we can get the project done in a few weeks.
> >
> > > > > > Volunteers?
> >
> > > > > I would love to get involved in this, as it's one of my recurring

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Marius]

Thoughts/comments on this?


Br's,
Marius

On Sep 22, 11:23 pm, Marius <[EMAIL PROTECTED]> wrote:
> one clarification .. by "by which the only benefit that I see is that
> *this* and MyType are actually of the same type sometimes leading to
> ease of writing expressions" are really meant that *this* and a that :
> MyType having the same type can give certain clarity of the
> expression. Just like SLS example 5.3.5
>
> Br's,
> Marius
>
> On Sep 22, 11:14 pm, Marius <[EMAIL PROTECTED]> wrote:
>
> > I'll do some noodling on this  ... starting first with understanding
> > of the design intent (which I assume it is founded on *ease of use*)
>
> > I see that Record follows the same parametrization paradigm ...
>
> > trait Record[MyType <: Record[MyType]] {
> >   self: MyType =>
>
> > ...
>
> > }
>
> > or
>
> > trait MetaRecord[BaseRecord <: Record[BaseRecord]] { self: BaseRecord
> > =>
> > ...
>
> > }
>
> > by which the only benefit that I see is that *this* and MyType are
> > actually of the same type sometimes leading to ease of writing
> > expressions. Is there another benefit?
>
> > The non benefit is that user needs to type somehow redundant stuff.
>
> > class MyRecord extends Record[MyRecord] {
>
> > ...
>
> > }
>
> > or
>
> > class MyMetaRecord[Rec <: MyRecord[MyMetaRecord]] extends
> > MetaRecord[Rec] {
>
> > ...
>
> > }
>
> > ... see I already typed MyRecord/Rec twice leading to a certain
> > redundancy. To me it is not really a drawback ... but I need to
> > understand if this paradigm is buying us a whole lot.
>
> > Br's,
> > Marius
>
> > On Sep 22, 9:05 pm, "David Pollak" <[EMAIL PROTECTED]>
> > wrote:
>
> > > Folks,
>
> > > For those who want to help, but are not yet Lift committers, please 
> > > contact
> > > me off-list and let's chat about you contributing to this project.
>
> > > If you're a committer, please look at the the wip-record2-dpp branch.  
> > > What
> > > I've been doing to start is to try to decompose the Mapper and Mapped*
> > > classes in Lift into composable traits in the net.liftweb.record package.
> > > Once we have a reasonable set of components we could compose together, 
> > > then
> > > we can start filling in the pieces.
>
> > > So... step 1, finish the decomposition of the Mapped* stuff into the 
> > > Record
> > > stuff.  Clean up the stuff that doesn't make sense (e.g., getSingleton ->
> > > meta... although this is on Mapper, but you get the idea).  How do we
> > > convert the field to/from String, XML, HTML Form, etc.?  What are the
> > > validation rules?  What are the access control rules (yes, this is already
> > > built into Lift's Mapper stuff)?
>
> > > Step 2, decompose the Mapper and MetaMapper stuff in the same way... 
> > > what's
> > > necesssary to map to/from XML, HTML forms, different storage mechanisms 
> > > etc.
>
> > > Step 3, fill in the core functionality... copy and paste whatever valuable
> > > code there is from Mapper (note than only about 20% of mapper is JDBC
> > > related).
>
> > > Step 4, build an abstraction layer for JPA so you can compose a JPA
> > > persisted Record just by mixing in the JPA adaptor... and the same for the
> > > JDBC adaptor, etc.
>
> > > Step 5, write a translation guide from Mapper -> Record
>
> > > Questions?
>
> > > Thanks,
>
> > > David
>
> > > PS -- on the validation front, currently, Mapper fields have a
> > > List[Function[T, List[ValidationIssue]]] that is the access to the
> > > server-side validation rules.  There exist a bunch of functions on
> > > MappedString, etc. to do common validations (min len, max len, regex, 
> > > etc.)
> > > In order to get client-side validation, we can have a subclass of Function
> > > that implements jsValidation: JsExp  That will be the cue to include the
> > > client-side validation in the form as it's being composed.  Cool, huh?
>
> > > On Mon, Sep 22, 2008 at 10:42 AM, Alex Cruise <[EMAIL PROTECTED]> wrote:
>
> > > > David Pollak wrote:
> > > > > I think the stuff that marius has done is interesting, but it is at
> > > > > odds with the long promised record/field stuff.
>
> > > > > This morning, I figured out how to ask the right questions in order to
> > > > > manage the record/field project. If I can get one or two volunteers, I
> > > > > think we can get the project done in a few weeks.
>
> > > > > Volunteers?
>
> > > > I would love to get involved in this, as it's one of my recurring pet
> > > > projects.  Unfortunately, like most of us, I don't have a lot of spare
> > > > time and my days are pretty much spoken for.  Maybe one way to start
> > > > would be for me to spew some of the design ideas I've had in this
> > > > department over the past year or so, and see if they resonate?
>
> > > > -0xe1a
>
> > > --
> > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > Collaborative Task Managementhttp://much4.us
> > > Follow me:http://twitter.com/dpp
> > > Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
You received thi

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[David Pollak]

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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Oliver Lambert]

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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[David Pollak]

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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Derek Chen-Becker]

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? 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).

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
>
>
>
>
>
>
> >
>

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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[David Pollak]

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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Charles F. Munat]

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.

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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Derek Chen-Becker]

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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Tim Perrett]

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

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Marius]

one clarification .. by "by which the only benefit that I see is that
*this* and MyType are actually of the same type sometimes leading to
ease of writing expressions" are really meant that *this* and a that :
MyType having the same type can give certain clarity of the
expression. Just like SLS example 5.3.5


Br's,
Marius

On Sep 22, 11:14 pm, Marius <[EMAIL PROTECTED]> wrote:
> I'll do some noodling on this  ... starting first with understanding
> of the design intent (which I assume it is founded on *ease of use*)
>
> I see that Record follows the same parametrization paradigm ...
>
> trait Record[MyType <: Record[MyType]] {
>   self: MyType =>
>
> ...
>
> }
>
> or
>
> trait MetaRecord[BaseRecord <: Record[BaseRecord]] { self: BaseRecord
> =>
> ...
>
> }
>
> by which the only benefit that I see is that *this* and MyType are
> actually of the same type sometimes leading to ease of writing
> expressions. Is there another benefit?
>
> The non benefit is that user needs to type somehow redundant stuff.
>
> class MyRecord extends Record[MyRecord] {
>
> ...
>
> }
>
> or
>
> class MyMetaRecord[Rec <: MyRecord[MyMetaRecord]] extends
> MetaRecord[Rec] {
>
> ...
>
> }
>
> ... see I already typed MyRecord/Rec twice leading to a certain
> redundancy. To me it is not really a drawback ... but I need to
> understand if this paradigm is buying us a whole lot.
>
> Br's,
> Marius
>
> On Sep 22, 9:05 pm, "David Pollak" <[EMAIL PROTECTED]>
> wrote:
>
> > Folks,
>
> > For those who want to help, but are not yet Lift committers, please contact
> > me off-list and let's chat about you contributing to this project.
>
> > If you're a committer, please look at the the wip-record2-dpp branch.  What
> > I've been doing to start is to try to decompose the Mapper and Mapped*
> > classes in Lift into composable traits in the net.liftweb.record package.
> > Once we have a reasonable set of components we could compose together, then
> > we can start filling in the pieces.
>
> > So... step 1, finish the decomposition of the Mapped* stuff into the Record
> > stuff.  Clean up the stuff that doesn't make sense (e.g., getSingleton ->
> > meta... although this is on Mapper, but you get the idea).  How do we
> > convert the field to/from String, XML, HTML Form, etc.?  What are the
> > validation rules?  What are the access control rules (yes, this is already
> > built into Lift's Mapper stuff)?
>
> > Step 2, decompose the Mapper and MetaMapper stuff in the same way... what's
> > necesssary to map to/from XML, HTML forms, different storage mechanisms etc.
>
> > Step 3, fill in the core functionality... copy and paste whatever valuable
> > code there is from Mapper (note than only about 20% of mapper is JDBC
> > related).
>
> > Step 4, build an abstraction layer for JPA so you can compose a JPA
> > persisted Record just by mixing in the JPA adaptor... and the same for the
> > JDBC adaptor, etc.
>
> > Step 5, write a translation guide from Mapper -> Record
>
> > Questions?
>
> > Thanks,
>
> > David
>
> > PS -- on the validation front, currently, Mapper fields have a
> > List[Function[T, List[ValidationIssue]]] that is the access to the
> > server-side validation rules.  There exist a bunch of functions on
> > MappedString, etc. to do common validations (min len, max len, regex, etc.)
> > In order to get client-side validation, we can have a subclass of Function
> > that implements jsValidation: JsExp  That will be the cue to include the
> > client-side validation in the form as it's being composed.  Cool, huh?
>
> > On Mon, Sep 22, 2008 at 10:42 AM, Alex Cruise <[EMAIL PROTECTED]> wrote:
>
> > > David Pollak wrote:
> > > > I think the stuff that marius has done is interesting, but it is at
> > > > odds with the long promised record/field stuff.
>
> > > > This morning, I figured out how to ask the right questions in order to
> > > > manage the record/field project. If I can get one or two volunteers, I
> > > > think we can get the project done in a few weeks.
>
> > > > Volunteers?
>
> > > I would love to get involved in this, as it's one of my recurring pet
> > > projects.  Unfortunately, like most of us, I don't have a lot of spare
> > > time and my days are pretty much spoken for.  Maybe one way to start
> > > would be for me to spew some of the design ideas I've had in this
> > > department over the past year or so, and see if they resonate?
>
> > > -0xe1a
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Collaborative Task Managementhttp://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 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
-~--~~~~--~~--~--

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Marius]

I'll do some noodling on this  ... starting first with understanding
of the design intent (which I assume it is founded on *ease of use*)

I see that Record follows the same parametrization paradigm ...

trait Record[MyType <: Record[MyType]] {
  self: MyType =>

...

}

or

trait MetaRecord[BaseRecord <: Record[BaseRecord]] { self: BaseRecord
=>
...
}

by which the only benefit that I see is that *this* and MyType are
actually of the same type sometimes leading to ease of writing
expressions. Is there another benefit?

The non benefit is that user needs to type somehow redundant stuff.


class MyRecord extends Record[MyRecord] {

...

}

or

class MyMetaRecord[Rec <: MyRecord[MyMetaRecord]] extends
MetaRecord[Rec] {

...

}

... see I already typed MyRecord/Rec twice leading to a certain
redundancy. To me it is not really a drawback ... but I need to
understand if this paradigm is buying us a whole lot.


Br's,
Marius

On Sep 22, 9:05 pm, "David Pollak" <[EMAIL PROTECTED]>
wrote:
> Folks,
>
> For those who want to help, but are not yet Lift committers, please contact
> me off-list and let's chat about you contributing to this project.
>
> If you're a committer, please look at the the wip-record2-dpp branch.  What
> I've been doing to start is to try to decompose the Mapper and Mapped*
> classes in Lift into composable traits in the net.liftweb.record package.
> Once we have a reasonable set of components we could compose together, then
> we can start filling in the pieces.
>
> So... step 1, finish the decomposition of the Mapped* stuff into the Record
> stuff.  Clean up the stuff that doesn't make sense (e.g., getSingleton ->
> meta... although this is on Mapper, but you get the idea).  How do we
> convert the field to/from String, XML, HTML Form, etc.?  What are the
> validation rules?  What are the access control rules (yes, this is already
> built into Lift's Mapper stuff)?
>
> Step 2, decompose the Mapper and MetaMapper stuff in the same way... what's
> necesssary to map to/from XML, HTML forms, different storage mechanisms etc.
>
> Step 3, fill in the core functionality... copy and paste whatever valuable
> code there is from Mapper (note than only about 20% of mapper is JDBC
> related).
>
> Step 4, build an abstraction layer for JPA so you can compose a JPA
> persisted Record just by mixing in the JPA adaptor... and the same for the
> JDBC adaptor, etc.
>
> Step 5, write a translation guide from Mapper -> Record
>
> Questions?
>
> Thanks,
>
> David
>
> PS -- on the validation front, currently, Mapper fields have a
> List[Function[T, List[ValidationIssue]]] that is the access to the
> server-side validation rules.  There exist a bunch of functions on
> MappedString, etc. to do common validations (min len, max len, regex, etc.)
> In order to get client-side validation, we can have a subclass of Function
> that implements jsValidation: JsExp  That will be the cue to include the
> client-side validation in the form as it's being composed.  Cool, huh?
>
>
>
> On Mon, Sep 22, 2008 at 10:42 AM, Alex Cruise <[EMAIL PROTECTED]> wrote:
>
> > David Pollak wrote:
> > > I think the stuff that marius has done is interesting, but it is at
> > > odds with the long promised record/field stuff.
>
> > > This morning, I figured out how to ask the right questions in order to
> > > manage the record/field project. If I can get one or two volunteers, I
> > > think we can get the project done in a few weeks.
>
> > > Volunteers?
>
> > I would love to get involved in this, as it's one of my recurring pet
> > projects.  Unfortunately, like most of us, I don't have a lot of spare
> > time and my days are pretty much spoken for.  Maybe one way to start
> > would be for me to spew some of the design ideas I've had in this
> > department over the past year or so, and see if they resonate?
>
> > -0xe1a
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Collaborative Task Managementhttp://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 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
-~--~~~~--~~--~--~---

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

[Charles F. Munat]

I'm definitely not skilled enough in Scala to be anything more than a 
drag at this point, but I hope you're going to post this stuff to the 
list as you go along. I'll do my best to learn it, and maybe my ignorant 
questions will spark a few ideas in more learned heads.

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.

My 0.5 cents.

Chas.

David Pollak wrote:
> Folks,
> 
> For those who want to help, but are not yet Lift committers, please 
> contact me off-list and let's chat about you contributing to this project.
> 
> If you're a committer, please look at the the wip-record2-dpp branch.  
> What I've been doing to start is to try to decompose the Mapper and 
> Mapped* classes in Lift into composable traits in the net.liftweb.record 
> package.  Once we have a reasonable set of components we could compose 
> together, then we can start filling in the pieces.
> 
> So... step 1, finish the decomposition of the Mapped* stuff into the 
> Record stuff.  Clean up the stuff that doesn't make sense (e.g., 
> getSingleton -> meta... although this is on Mapper, but you get the 
> idea).  How do we convert the field to/from String, XML, HTML Form, 
> etc.?  What are the validation rules?  What are the access control rules 
> (yes, this is already built into Lift's Mapper stuff)?
> 
> Step 2, decompose the Mapper and MetaMapper stuff in the same way... 
> what's necesssary to map to/from XML, HTML forms, different storage 
> mechanisms etc.
> 
> Step 3, fill in the core functionality... copy and paste whatever 
> valuable code there is from Mapper (note than only about 20% of mapper 
> is JDBC related).
> 
> Step 4, build an abstraction layer for JPA so you can compose a JPA 
> persisted Record just by mixing in the JPA adaptor... and the same for 
> the JDBC adaptor, etc.
> 
> Step 5, write a translation guide from Mapper -> Record
> 
> Questions?
> 
> Thanks,
> 
> David
> 
> PS -- on the validation front, currently, Mapper fields have a 
> List[Function[T, List[ValidationIssue]]] that is the access to the 
> server-side validation rules.  There exist a bunch of functions on 
> MappedString, etc. to do common validations (min len, max len, regex, 
> etc.)  In order to get client-side validation, we can have a subclass of 
> Function that implements jsValidation: JsExp  That will be the cue to 
> include the client-side validation in the form as it's being composed.  
> Cool, huh?
> 
> On Mon, Sep 22, 2008 at 10:42 AM, Alex Cruise <[EMAIL PROTECTED] 
> > wrote:
> 
> 
> David Pollak wrote:
>  > I think the stuff that marius has done is interesting, but it is at
>  > odds with the long promised record/field stuff.
>  >
>  > This morning, I figured out how to ask the right questions in
> order to
>  > manage the record/field project. If I can get one or two
> volunteers, I
>  > think we can get the project done in a few weeks.
>  >
>  > Volunteers?
>  >
> I would love to get involved in this, as it's one of my recurring pet
> projects.  Unfortunately, like most of us, I don't have a lot of spare
> time and my days are pretty much spoken for.  Maybe one way to start
> would be for me to spew some of the design ideas I've had in this
> department over the past year or so, and see if they resonate?
> 
> -0xe1a
> 
> 
> 
> 
> 
> -- 
> 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 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
-~--~~~~--~~--~--~---