[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]
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]
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]
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
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
[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]
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 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
[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]
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]
mailto:[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]
mailto:[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] mailto:[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]
mailto:[EMAIL PROTECTED]and turn it into [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
override def validations =
valRegex(^[a-z0-9._%-]+@(?:[a-z0-9-]+\\.)+[a-z]{2,4}$
mailto:[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
[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]
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]
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]
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
HTML
HEAD
SCRIPT language=Javascript
!--
function isNumberKey(evt)
{
var charCode = (evt.which) ? evt.which : event.keyCode
if (charCode 31 (charCode 48 || charCode 57))
return false;
return true;
}
//--
/SCRIPT
/HEAD
BODY
INPUT id=txtChar onkeypress=return isNumberKey(event)
type=text name=txtChar
/BODY
/HTML
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
-~--~~~~--~~--~--~---
