PHP Pear - Re: [PEAR] QFC Back/Next buttons driving me crazy

Author

Re: [PEAR] QFC Back/Next buttons driving me crazy

Justin Patrin

2005-06-02, 8:57 pm

On 6/2/05, Ken Restivo <ken@restivo.org> wrote:
> I've determined that trying to build a modern user interface out of HTML =
is like trying to make a bookshelf out of mashed potatoes[0]-- it was never=
designed for that. QF/QFC is a tremendous help in some ways, but makes oth=
er things (like weird workarounds) much more difficult and complicated.
>=20
> In western cultures where we read left-to-right, nav buttons should be in=
the order [<< Back] [Next >>] . And QFC wants both of the buttons to be Su=
bmit buttons. OK fine.
>=20
> Problem is, when users hit "enter" to go to the next page, the BACK butto=
n gets triggered, because it is first, and browsers seem to insist on that.=
Auugh.

What do you mean by "browsers"? Which have you tried in? I'm
absolutely sure that IE doesn't do this. Of course I'm a FireFox
person and FireFox *does* seem to do this....

Oh, but now there's a problem. If there's only one text box then IE
doesn't send the button value, but if there are 2 it does. What the
hell is MS smoking?

http://ppewww.ph.gla.ac.uk/~flavell...rmquestion.html is an
interesting read in this regard.

>=20
> I have $page->setDefaultAction('next'). The hidden qf_default is getting =
passed correctly through in the submitvalues all right, but the browser is =
also explicitly sending the BACK action, so QFC is ignoring the hidden defa=
ult action.
>=20
> So instead I tried making the BACK button a 'button', not a 'submit'. Som=
e browsers are OK with that, others do stupid things like submit BOTH butto=
ns on enter. And guess which button QFC heeds? The one that comes first: BA=
CK. Gah.
>=20

Again, which does which? How about if you add both back and next as
buttons instead of submits?

> I found a nifty article (http://volition.vee.net/archives/000498.html) wh=
ich suggests using CSS2 to assign a style "direction: rtl;" attribute to re=
verse the order of the buttons on display; thus I can have them in the code=
in the order the browser wants to see, but the user will see them in a san=
e order. Pretty slick.
>=20

This is a hack and should definately be seen as such.

> So I tried assigning a style or class attribute to the group that has my =
nav buttons. Maybe I'm missing something, but addGroup doesn't take attribu=
tes, nor does $group->updateAttributes() seem to work.
>=20
> So, what do I have to do? Subclass the group element and manually jack wi=
th the renderer to wrap a div around the group with the rtl direction? That=
seems like a crazily complicated hack to do something which should be the =
default behaviour.
>=20
> I can't be the first person to have run into this. Maybe I'm missing some=
thing obvious and I'm just too frustrated to see what it is.
>=20

This does seem like a bad problem. To quote from the website I list above:
----
If you have several "submit controls", and one of them performs an
operation which is sufficiently drastic, then I would recommend that
you consider some alternative way of protecting against accidental
invocation of this operation. In view of the uncertainties described
in this page, it seems advisable to avoid relying on multiple submit
controls in such critical cases: instead, you could use some kind of
checkbox or select control to indicate the desired function, with the
defaults set for a harmless preview of the requested operation, and
the critical operation(s) requiring some positive action by the user
before submission: the actual form submission being done with a single
Submit control. Examples that have been seen in practice are e.g an
ordering form with a final checkbox "I have read and agree to the
terms of ordering from this site", and without which the actual order
will not be accepted; another example was a collaborative editing site
with a select pulldown "Preview changes so far" (default) and "Submit
revised document".
----

So it looks like there's no easy way to handle this. From some quick
tests it seems that if a submit button is sent via pressing enter in a
text field then the onclick handler for the button is sent. This is
completely stupid and wrong as the button was clearly not clicked, but
this is what the browser does. I would suggest either to try to add
some JS which doesn't let people submit via the enter button or to add
some onclick javascript to the buttons which checks for focus. If the
focus is not on a button then the default action should be sent,
otherwise send the button clicked. (Actually that should work pretty
well...)

And you could also use the rtl thing in a template for the element. ;-)

--=20
Justin Patrin

Ken Restivo

2005-06-04, 3:56 pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Jun 04, 2005 at 05:39:35PM +0200, Golgote wrote:
> I add a submit on top of my form that I hide using css and display:none;
> I also add a setDefaultButton() method or something like that to my
> QF_Page extension.
>

Thank you, thank you, thank you! That is just exactly the right level of hackage to get around these idiotic browsers. It's the simplest and easiest solution, creates the minimum amount of churn in my code... and it works! Yippie!

- -ken
- --
- ---------------
The world's most affordable web hosting.
http://www.nearlyfreespeech.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCoeM2e8HF+6xeOIcRAsSAAKC5vHgbcv0G
MJYhMWM62FcGoQZkIACgzH8y
1iAdPybNL6Yeh3M8zSEvQ0w=
=8uoS
-----END PGP SIGNATURE-----

Sponsored Links