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 fo
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
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 bo
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
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
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
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(
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.err
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
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
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 s
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, th
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.
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
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 sur
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 Tu
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
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 *thi
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 map
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
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
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
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 th
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
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 somethin
> 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 not
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 ex
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[BaseR
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 thou
29 matches
Mail list logo
