HTML_QuickForm DHTML client rules and SoftRequired rule

Justin Patrin wrote:

> Please don't make general statements like this. These
are all things 
> that you may or may not want. *You* may not like it,
...

Sorry, my mail wasn't meant to offend you. Actually my last
sentence
contained the phrase "in my opinion", I must
have deleted it while
correcting the sentence.

> but I think it's pretty cool ...

It is cool.  But it
also has some problems, as described. When I
don't have done anything with this "soft
required" field, then the
question is really bogus.

> In fact, if the top of a form was off the screen,
clicking submit
> with this new JS could cause them to not even see the
errors.

True, I will have to consider this for the usage in my
projects.

> You can just comment out the code which adds the event
handlers to
> the elements if you don't like them or simply remove
the overridden 
> display() function.

Right, that's what I also wrote. And that's the behavior
of the old code.

I just wanted to point out that you had a nice idea and made
a nice 
implementation. But it also has -- in my opinion -- some
problems.
(And in your original post you asked for comments.)

Regards,
Mark

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 3/27/06, Mark Wiesemann <wiesemannphp.net> wrote:
> Justin Patrin wrote:
>
> > Please don't make general statements like this.
These are all things
> > that you may or may not want. *You* may not like
it, ...
>
> Sorry, my mail wasn't meant to offend you. Actually my
last sentence
> contained the phrase "in my opinion", I
must have deleted it while
> correcting the sentence.
>

Sorry, I'll moderate my reading.

> > but I think it's pretty cool ...
>
> It is cool.  But it
also has some problems, as described. When I
> don't have done anything with this "soft
required" field, then the
> question is really bogus.

But you did. You gave the element focus (tabbing to it or
clicking on
it), then took the focus away (tabbing out of it or clicking
elsewhere). This constitues interacting with the element.
Since you've
interacted with the element but not done anything, it lets
you know
that there is a potential problem.

Again, this is more of a question of opinion. When would you
like the
error checking to happen? If not onBlur or onKeyUp, the only
possibility left is onSubmit (unless you want to do it
onMouseOver or
onMouseOut, which I doubt). If you leave validation to
onSubmit then
you can have the other problems I've outlined. IMHO it's
better to at
least have the onBlur as it lets the user know, right after
they've
filled out the form, that they need to fix something.

>
> > In fact, if the top of a form was off the screen,
clicking submit
> > with this new JS could cause them to not even see
the errors.
>
> True, I will have to consider this for the usage in my
projects.
>
> > You can just comment out the code which adds the
event handlers to
> > the elements if you don't like them or simply
remove the overridden
> > display() function.
>
> Right, that's what I also wrote. And that's the
behavior of the old code.
>
> I just wanted to point out that you had a nice idea and
made a nice
> implementation. But it also has -- in my opinion --
some problems.
> (And in your original post you asked for comments.)
>

Thanks for the discussion. 

--
Justin Patrin

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi,

> Again, this is more of a question of opinion. When
would you like the
> error checking to happen? If not onBlur or onKeyUp, the
only
> possibility left is onSubmit (unless you want to do it
onMouseOver or
> onMouseOut, which I doubt). If you leave validation to
onSubmit then
> you can have the other problems I've outlined. IMHO
it's better to at
> least have the onBlur as it lets the user know, right
after they've
> filled out the form, that they need to fix something.

IMHO the behaviour for the e-mail element in your example is
wrong. When 
I want to input my e-mail address in the first field, and
just type in 
the first letter, it turns red indicating an error. At that
point I 
didn't make an error, I was just not finished typing.

In my opinion it should indicate an error if the user is
creating an 
error. So it shouldn't show an error if the user is still
typing an 
e-mail address, but it should show it on the onBlur when it
isn't 
finished yet. The way it is now, is that a customer thinks
after typing 
the first char that he did something wrong, while he
actually didn't.

I hope you guys follow me on this .

Kind regards,

Maarten Bremer

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Justin Patrin wrote:

> But you did. You gave the element focus (tabbing to it
or clicking on
> it), then took the focus away (tabbing out of it or
clicking
> elsewhere).

No. Just try yourself: Put the cursor into the second form
field. Then 
hit the tabular key and see what happens. I've tested it
with IE 6 and 
Firefox 1.5 and got immediately the question. This is not
what I (and 
maybe also you) expect.

> This constitues interacting with the element. Since
you've
> interacted with the element but not done anything, it
lets you know
> that there is a potential problem.

In the way you describe it, the behavior is okay and the
question makes 
sense.

> Again, this is more of a question of opinion. When
would you like the
> error checking to happen? If not onBlur or onKeyUp, the
only
> possibility left is onSubmit (unless you want to do it
onMouseOver or
> onMouseOut, which I doubt). If you leave validation to
onSubmit then
> you can have the other problems I've outlined. IMHO
it's better to at
> least have the onBlur as it lets the user know, right
after they've
> filled out the form, that they need to fix something.

Your point is valid, although I like these
"early" messages not that 
much. I will play with your code in the next days and look
for a 
solution that makes me really happy. 

Regards,
Mark

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 3/27/06, Maarten Bremer <maartenxolphin.nl> wrote:
> Hi,
>
> > Again, this is more of a question of opinion. When
would you like the
> > error checking to happen? If not onBlur or
onKeyUp, the only
> > possibility left is onSubmit (unless you want to
do it onMouseOver or
> > onMouseOut, which I doubt). If you leave
validation to onSubmit then
> > you can have the other problems I've outlined.
IMHO it's better to at
> > least have the onBlur as it lets the user know,
right after they've
> > filled out the form, that they need to fix
something.
>
> IMHO the behaviour for the e-mail element in your
example is wrong. When
> I want to input my e-mail address in the first field,
and just type in
> the first letter, it turns red indicating an error. At
that point I
> didn't make an error, I was just not finished typing.
>
> In my opinion it should indicate an error if the user
is creating an
> error. So it shouldn't show an error if the user is
still typing an
> e-mail address, but it should show it on the onBlur
when it isn't
> finished yet. The way it is now, is that a customer
thinks after typing
> the first char that he did something wrong, while he
actually didn't.
>
> I hope you guys follow me on this .
>

Yep, makes sense. I've commented out the onKeyUp event
setting for now
since this seems to cause more problems that it fixes.

--
Justin Patrin

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 3/27/06, Mark Wiesemann <wiesemannphp.net> wrote:
> Justin Patrin wrote:
>
> > But you did. You gave the element focus (tabbing
to it or clicking on
> > it), then took the focus away (tabbing out of it
or clicking
> > elsewhere).
>
> No. Just try yourself: Put the cursor into the second
form field. Then
> hit the tabular key and see what happens. I've tested
it with IE 6 and
> Firefox 1.5 and got immediately the question. This is
not what I (and
> maybe also you) expect.
>

Aha, I see. I didn't realize this had happened. This was
due to the
onKeyUp event. I've commented this out for now as people
seem not to
like it in general.

> > This constitues interacting with the element.
Since you've
> > interacted with the element but not done anything,
it lets you know
> > that there is a potential problem.
>
> In the way you describe it, the behavior is okay and
the question makes
> sense.
>
> > Again, this is more of a question of opinion. When
would you like the
> > error checking to happen? If not onBlur or
onKeyUp, the only
> > possibility left is onSubmit (unless you want to
do it onMouseOver or
> > onMouseOut, which I doubt). If you leave
validation to onSubmit then
> > you can have the other problems I've outlined.
IMHO it's better to at
> > least have the onBlur as it lets the user know,
right after they've
> > filled out the form, that they need to fix
something.
>
> Your point is valid, although I like these
"early" messages not that
> much. I will play with your code in the next days and
look for a
> solution that makes me really happy. 
>

Sounds good.

--
Justin Patrin

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php