I hate this too: form[0][-1][1]. I have a pending patch that will allow you to grab parent and sibling elements so you can do: >>> form = SQLFORM(db.whatever) >>> submit = form.element(_type='submit') >>> submit.parent.append(INPUT(_type='submit',_value='Cancel'))
A little more verbose but human readable and appending the button will stay relative to where the submit button is. Massimo, have you had a chance to look at this? On Feb 7, 3:24 pm, Jonathan Lundell <jlund...@pobox.com> wrote: > On Feb 6, 2010, at 9:33 PM, Iceberg wrote: > > > > > On Feb7, 8:01am, Jonathan Lundell <jlund...@pobox.com> wrote: > >> On Feb 6, 2010, at 12:58 PM, Jonathan Lundell wrote: > > >>> On Feb 6, 2010, at 12:38 PM, mdipierro wrote: > > >>>> form[0][-1][1].append(BUTTON(_onclick="....")) > > >>> Thanks. > > >>> Ideally, I'd like to return to the form.accepts call in such a way that > >>> the accepts return test can recognize the cancelation and then redirect > >>> as necessary. Somewhat parallel to testing form.error, I'd test (say) > >>> form.cancel. > > >>> Does that make sense? It seems to me that it might be a useful general > >>> capability for form processing. > > >>> One angle I was thinking of, but haven't investigated, is having multiple > >>> submit buttons, with accepts() making available the name and/or value of > >>> the button that was clicked. > > >>> That seems more in keeping with the self-submit philosophy, don't you > >>> think? > > > Yes, but be careful of multiple submit buttons. See this post: > > https://groups.google.com/group/web2py/browse_frm/thread/f44b6f95b058df5 > > I'll need to look at that more closely. Thanks. Perhaps I can use <button> > and JavaScript. > > > > > > >> I think I got it to work. > > >> form[0][-1][1].append(INPUT(_type="submit", _name="button", > >> _value="Cancel")) > > >> and then after calling accepts: > > >> if request.vars.button == "Cancel": > >> session.flash = 'edit canceled' > >> else: > >> session.flash = "edit accepted" > >> redirect(URL(r=request, f='servers')) > > >> ...or something similar in the form.error case. > > >> (I find that I'm a little fuzzy on the various return cases for accepts, > >> though.) > > > That is inevitable since you need to handle two different situations > > in one action. So I would suggest just use a normal html reset button > > at most. > > Reset doesn't do it for me; I need an actual cancel function that can do a > specified page load. > > > > >> Question: what exactly is form[0][-1][1].append appending to? Can I append > >> more than once to that same object? > > > Yes. FORM is a container for many components. You can change it if you > > want to. But a more readable style should be: > > form = FORM( > > ... # all the normal stuff > > INPUT(_type='submit'), > > INPUT(_type='reset'), > > ) > > Except it's an SQLFORM, which won't accept INPUT arguments. > > The big problem with form[0][-1][1].append is that it "knows" too much about > the internal structure of form. I can't expect the guarantee of backward > compatibility to include constructs like that. > > So I'm left with two problems. The IE with multiple submits, and adding a > button to the SQLFORM. Both are semi-solved, I think, but not in an ideal way. -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
