Subscribe for automatic updates: RSS icon RSS

Login icon Sign in for full access | Help icon Help
Advanced search

Pages: [1]
  Reply  |  Print  
Author Topic: launchURL Front Call  (Read 113 times)
Gary C.
Posts: 111


« on: May 04, 2025, 03:21:04 pm »

Hi
We have finally made the move from FGL 3.21 to 5.01 but have noted a behaviour we cannot explain when using the launchURL front call in conjunction with ui.Interface.filenameToURI to display stored documents.

We have a centralised function to do this as all documents are stored in a single document archive. The function is as below:

Code
  1. #+
  2. #+ View a document by its ID
  3. #+
  4. #+ This function allows the user to download a document for viewing
  5. #+
  6. #+ The public record will be set holding the document ID and its actual name
  7. #+
  8. #+ Documents are stored by ID in an archive folder (the root of which is held in environment variable: FGL_DOCUMENTROOT)
  9. #+ IDs are prepended with zeros to make them 12 characters in length, e.g. 215168 becomes 000000215168
  10. #+ The folder structure for the above document is then:
  11. #+
  12. #+ $(FGL_DOCUMENTROOT)/000/000/215/000000215168
  13. #+
  14. #+ @return Nothing
  15. #+
  16.  
  17. function sys_viewDocumentByID()
  18.  
  19.    define sFileSource,
  20.        sFileDestination,
  21.        sDocumentUri string
  22.  
  23.    if p_documentR.documentid is null then
  24.        return
  25.    end if
  26.    if p_documentR.documentname is null then
  27.        return
  28.    end if
  29.  
  30. # Get the full path to the document within the archive
  31.  
  32.    let sFileSource = sys_getDocumentPath(p_documentR.documentid)
  33.    if sFileSource is null then
  34.        return
  35.    end if
  36.  
  37. # If using GBC, copy the document to the temporary area, renaming at the same time
  38. # If all is well, get the URI and make the front call
  39.  
  40.    if ui.Interface.getFrontEndName() = "GBC" then
  41.        try
  42.            let sFileDestination = os.Path.join(g_tmpServerDir.trim(), p_documentR.documentname.trim())
  43.            if os.Path.copy(sFileSource, sFileDestination) then
  44.                let sDocumentUri = ui.Interface.filenameToURI(sFileDestination)
  45.                call ui.Interface.frontCall("standard", "launchURL", [sDocumentUri], [])
  46.            end if
  47.        catch
  48.            call sys_showMessage(%"Error", sfmt(%"Unable to download file %1 to %2 (%3)", sFileSource,  sFileDestination, status), "")
  49.        end try
  50.        return
  51.    end if
  52.  
  53.    try
  54.        let sFileDestination = g_tmpClientDir.trim(), g_clientPathSeperator.trim(), p_documentR.documentname.trim()
  55.        call fgl_putfile(sFileSource, sFileDestination)
  56.        call sys_launchDocument(sFileDestination)
  57.    catch
  58.        call sys_showMessage(%"Error", sfmt(%"Unable to download file %1", sFileSource)||CRLF||sfmt("To: %1", sFileDestination), "")
  59.        return
  60.    end try
  61.  
  62. end function
  63.  

For the time being we are able to run our codebase using FGL 3.21 or 5.01, hence the check for the front end type.

The above works well when the filename of the document has no spaces, e.g. image01.jpg, but fails when there are spaces.

For example, a filename of "Meeting Report.pdf" will fail. The result is the following URI, for which we get a bad request response in the browser:

https://app.alsico.co.uk/gas/ua/ft/6f73f925533f0d5470e57ba6ea7b762a/fgl-files/82966/Meeting%20Report.pdf?t=1746363820;s=461534;charset=UTF-8

However, if we replace the spaces with an underscore, i.e. "Meeting_Report.pdf", this results in a URI such as below, which works:

https://app.alsico.co.uk/gas/ua/ft/831139bc472031110b9fe19ea07f7add/fgl-files/82994/Meeting_Report.pdf?t=1746363908;s=461534;charset=UTF-8

Can anyone see any issues in the above code? Though the workaround is fine, it would be better for us not to have to manipulate the file name.

Thanks in advance

Gary
Leo S.
Four Js
Posts: 131


« Reply #1 on: May 04, 2025, 11:46:07 pm »

Hi Gary, works for me with  FGL 5.01.02 and httdispatch 5.01.01 ... see attached.
Try at your side and if this doesn't work with your env contact the support.

I'd like to point you for displaying PDF's "inlined" to a simple webcomponent I came up with: it doesn't open a 2nd tab and you could integrate more seamless into your workflow.
Since 4.x it works painless in GBC and GDC (exception safari mobile: only the 1st page of the pdf is displayed as an image because it seems an iframe limitation of safari mobile).
Previously pdfjs was needed to render PDFs in a Genero Form, nowadays browsers are capable of displaying their own GUI for showing PDFs in an iframe.
See https://github.com/leopatras/wc_simplepdf
Regards, Leo

* pdf_spaces.zip (2.12 KB - downloaded 3 times.)
Reuben B.
Four Js
Posts: 1134


« Reply #2 on: Today at 12:10:08 am »

Gary,

You are light in details on what the front-end is, but is this a possibility https://4js.com/online_documentation/fjs-gas-manual-html/#gas-topics/c_gas_mode_proxy_fcgi_spaces_in_filenames.html

Reuben

Product Consultant (Asia Pacific)
Developer Relations Manager (Worldwide)
Author of https://4js.com/ask-reuben
Contributor to https://github.com/FourjsGenero
Gary C.
Posts: 111


« Reply #3 on: Today at 01:11:12 pm »

Hi
Thanks Leo, I'll look at your component as we may have a good use case for this.

Reuben, thanks, that was the issue. We are using Apache 2.4.52 on Ubuntu, but our proxy.conf file was incorrect and had the pre 2.4.11 settings.

Gary
Pages: [1]
  Reply  |  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines