The FileMaker Web Viewer Bridge raises our interaction between FileMaker and JavaScript to the next level. Let’s take a high-level view of this framework.

Working with the web viewer, stage one

In all the work I’ve done so far with JavaScript and FileMaker, I’ve followed one setup. The JavaScript libraries, functions, the CSS, and the HTML are all stored in FileMaker fields. These fields’ contents are calculated together into a single calc field, and this is the field a web viewer uses as its source. For much of the work I’ve done, this method is sufficient. I can display a date picker or a data tables list of actual data from the custom app using this method. It worked.

The Problems

When I want to do more, this method causes a few problems. If I’m using the DataTables JavaScript library to show a portal-looking list of related data and a new record gets added to the related set, I’d have to make sure to add that data to the web viewer’s view. And that requires reloading all the JS libraries into the web viewer. The screen cap below shows the problem.

Likewise, it is a problem when the use case requires a button to make a change to how the web viewer shows its information. If I have a chart, and I want the chart to transform from a bar chart to a line chart, I’d have to update the chart options from “bar” to “line” in the JS function text field (which I could do using Filemaker Scripting).

Both of these possible use cases cause a problem to the experience of using the web viewer. Watch the movie below showing the DataTables JavaScript library integration and see if you spot the problem.

Let’s breakdown what happened

  1. This JavaScript configuration was set up to sort by last name Desc by default. Every time this web viewer loads, those records with last name starting with “Z” shows up at the top.
  2. I sorted by Last Name Ascending.
  3. I added a new related record to the table using a popover, global fields, and a script.
  4. When I pressed “Add Row”, a script ran to grab the related data of this one parent record. The script formatted the data properly and then set the data in the Data field.
  5. This field refresh triggered the web viewer to reload.
  6. When the web viewer reloaded, it took the calculated HTML document and reloaded it into the web viewer, causing the flash and causing the sort state to be reset to its default for this configuration.

Bridging FileMaker and JavaScript

The FileMaker Web Viewer Bridge solves the problems described above. This framework bridges the FileMaker platform and any JS libraries you are using, forming, as most bridges do, a two-way connection. FileMaker can ‘talk’ to the JS loaded into a web viewer, and the web viewer can call back to FileMaker.

Here’s what it looks like.

Did you see it? Let’s breakdown what did and didn’t happen.

  1. I sorted the data using both position and Last Name (yes, that’s built into DataTables).
  2. I used a FileMaker popover, global fields, and a FileMaker script to add a new record.
  3. When the record was added:
    1. The new row immediately appeared
    2. The sort state did not change
    3. The record was added to the rows, there was no flash.

We still loaded the new record into the web viewer, but we did so without resetting the web viewer. That’s the power of the FileMaker Web Viewer Bridge. The popover I used to add the record contained a button that ran a FileMaker script. That FileMaker script sent the new record’s data to the JavaScript library, calling a function in DataTables JS to add a row.

Calling back to FileMaker

Just as we can use FileMaker to call a JavaScript function, the FileMaker Web Viewer Bridge allows a JavaScript function to call a FileMaker script. This could already happen using the fmp protocol, and indeed the Web Viewer Bridge uses the FMP protocol. The complex syntax of the statement is removed.

The Devil’s in the details

We’ll go into detail about how you can use the FileMaker Web Viewer Bridge to accomplish the above tasks for any JS library in future posts and videos. There’s some specific points to cover. We cover the following topics:

  • Setting up the JavaScript to run FileMaker Scripts
  • Setting up the JavaScript to allow FileMaker to call a JS function.
  • Loading all HTML / CSS / JS into the web viewer.
  • Connecting to the FileMaker Web Viewer Bridge
  • Sending data created in FileMaker to a JavaScript function
  • Calling back from JavaScript to FileMaker

There will probably be other topics along the way.

It’s for Everyone

The power of the FileMaker Web Viewer bridge, all of the possibility it opens up, is not beyond your skill as a FileMaker developer and a budding JavaScript developer. Yes, you’ll have to learn some JavaScript, but we’ll cover that together and in minute detail.

Download the sample shown in the screen casts above as well as the original FileMaker Web Viewer Bridge file. Read through the documentation (found there on Github) and stay tuned here to learn more about the FileMaker Web Viewer Bridge.

6 responses to “The FileMaker Web Viewer Bridge”

  1. Christian Ganglmair says:

    Hi

    Thank you for the great example. My problem is, that all my callbacks from javascript to filemaker are causing an error message saying, that the file “FM-WebViewer-Bridge.fmp12″ could not be opened. Either the host is not available, or the file is not available on that host.”

    What also happens is, that the callback starts my fmpa 16 client although i opened the file with fmpa 17.

    Do you have any ideas how I can fix this?

    Thanks
    Christian

  2. Christian Ganglmair says:

    Hi Jeremy

    Thank you for your help. I was able to make it work with the rubicode-tool. Now everything seems to work fine and I can go on with my experiments 😉

  3. Christian Ganglmair says:

    Hi Jeremy

    I experimented with the FM Web Viewer Bridge and tried to implement it in my solution.
    I took the code of fm-webviewer-bridge.umd.js and stored it in a field like other .js-files and copied the module and the two script files LoadWebApp From Text Field and Export HTML File.
    The index.html-file is created and does show up in the web viewer but I always get two errors:
    – Cross origin requests are only supported for HTTP
    – XMLHttpRequest cannot load file:///data.json due to access control checks.

    If I use the example file, I don’t get those errors (but the lib gets loaded through the internet).

    What am I missing here?

    Thank you for your support
    Christian

  4. […] session. We were able to integrate the C3 Charting library and cause it to change without the web viewer flashing as the code reloads and without the rendered chart losing its state. (Again, we’ll come back […]

Leave a Reply