Re: QFC Back/Next buttons driving me crazy

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 other things (like weird workarounds) much more difficult and > complicated. > > 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 Submit buttons. OK fine. > > Problem is, when users hit "enter" to go to the next page, the BACK button 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/www/formquestion.html is an interesting read in this regard. > > 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 default action. > > So instead I tried making the BACK button a 'button', not a 'submit'. Some > browsers are OK with that, others do stupid things like submit BOTH buttons on enter. And guess > which button QFC heeds? The one that comes first: BACK. Gah. > 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) which suggests using > CSS2 to assign a style "direction: rtl;" attribute to reverse 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 sane order. Pretty slick. > 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 attributes, nor does > $group->updateAttributes() seem to work. > > So, what do I have to do? Subclass the group element and manually jack with 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. > > I can't be the first person to have run into this. Maybe I'm missing something > obvious and I'm just too frustrated to see what it is. > 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. ;-) -- Justin Patrin