Submit button title not properly restored after "Working..."

[ensenbach]

Hello,

in a controller I construct a FORM with two submit buttons:

def index():
    if request.vars["getpdf"]:
        response.headers["Content-Type"] = "application/pdf"
        return ""
    form = FORM()
    form.append(INPUT(_name="addfield", _type="submit", _value="add field"))
    form.append(INPUT(_name="getpdf", _type="submit", _value="get pdf"))
    return dict(form=form)

When I click on the "get pdf" button, all buttons are first disabled ("Working..."), then are again enabled but with both buttons reading "add field". Is there a way to have the second button get back its original title "get pdf"?

Best regards

Marc

[Val K]

It's unexpectedly, that the form is still alive after "getpdf", because the controller doesn't return any form (unless it's an ajax-request).

I think, If you want to return a pdf that depends on some args/vars then better to have the separated controller:

def pdfcontroller():
   if request.args(0) == "monthly":

        ...
   # and/or:
   if request.vars.some:
      ....
   response.headers["Content-Type"] = "application/pdf"
   return  pdfcontent

So, you could use it anywhere by URL("pdfcontroller", args=[...], vars = dict(...)):

    

if form.process().accepted:
   redirect(URL("pdfcontroller", args=[form.vars.report_type], vars = dict(month = form.vars.month, anothervar= form.vars.somevar)))

or just as A-element:

A ("get pdf ", _href = URL(...))

[ensenbach]

Am Dienstag, 22. August 2017 21:00:18 UTC+2 schrieb Val K:

It's unexpectedly, that the form is still alive after "getpdf", because the controller doesn't return any form (unless it's an ajax-request).

It might be a little bit unexpected, but since also the web2py default admin application makes use of such forms (see e.g. the "pack individually" form for applications), I believe that it should be supported by web2py.
 

I think, If you want to return a pdf that depends on some args/vars then better to have the separated controller: [...]

This might be a solution, but since here the user should be able to continue working with the form (e.g. generate another PDF after a slight modification of the form values), this would entail handing over the complete form data to the new controller, then back to the original controller and then repopulate the form. This seems to be quite cumbersome to me. Or is there an elegant way of achieving the "persistance" of form entries in this case?

Best regards

Marc

[Anthony]

This a bug -- I just submitted a pull request to fix it: https://github.com/web2py/web2py/pull/1746.

For now, you can make that same change in your own web2py.js.

Note, this is only an issue if (a) you have a form with multiple submit buttons and (b) clicking one of the submit buttons returns a file attachment.

Also, technically, the code you have shown below does not actually result in a problem because the "Content-Disposition" of the file is not set to "attachment", so the browser simply displays the (empty) PDF in place of the original page before the buttons are re-enabled. The problem only appears if you add:

response.headers["Content-Disposition"] = 'attachment'

Anthony

[ensenbach]

Am Mittwoch, 23. August 2017 17:58:45 UTC+2 schrieb Anthony:

This a bug -- I just submitted a pull request to fix it: https://github.com/web2py/web2py/pull/1746.

For now, you can make that same change in your own web2py.js.

Thank you for providing the fix. I have adopted the changes in my web2py installation and everything works now as expected.
 

Also, technically, the code you have shown below does not actually result in a problem because the "Content-Disposition" of the file is not set to "attachment", so the browser simply displays the (empty) PDF in place of the original page before the buttons are re-enabled.

I had the Content-Disposition set correctly in my original code but happened to strip to much when creating the short example (which I did not notice since I disabled embedded pdf display in my browser).

Best regards

Marc