Writing JavaScript in FileMaker is hard. Sure, the path is easy to see and clear to follow, but the actual writing of the code is hard. I have tried to find a way to write JS code that makes it fairly easy. And by “easy,” I mean “make it so that FileMaker developers don’t have to learn a hundred skills to get JS to work in FM – other than the JS itself.” I’m striving for a better JavaScript Development Environment.

An Okay JS Development Environment

My first attempt was writing or placing code in FileMaker fields. That worked…and it didn’t. There’s a lot of advantages to this method, but there are as many disadvantages (a fact I was reminded of in session feedback comments and emails about the demos I’ve released). We’re just writing in a text field – there’s no automatic formatting of the code, and there’s not any helpful type-ahead or auto complete features. There’s a lot wrong with this. Even my attempts to use a code editor JavaScript library to render the code from a text field proved only marginally better.

I continued doing this method many times (here, here, and here) always knowing that this isn’t ideal.

But recently, Kevin Frank approached me about a JS project. Working with him on this JSON-parsing library, I took it as an opportunity to finally come up with a better way of developing JavaScript in FileMaker. Kevin has written about it in his post FileMaker 19 + JSONata. Check out the details of the origin and use. We also recorded a podcast episode about it – check that out.

Towards a Better JS Development Environment

After all of our work with JavaScript in FileMaker, we’ve come to our current definition of a better JS development environment. To be effective with our coding time, here’s what a ‘better development method’ must include:

  1. Using a proper HTML/JS code editor.
  2. Immediate rendering or performing of the code in the FileMaker web viewer object.
  3. Using data from the FileMaker app.
  4. Using the result of the JavaScript processing in FileMaker.

Let’s tackle each one of these and use my work with Kevin as illustration.

A Proper Editor

Writing JavaScript is a piece of cake when one has an integrated development environment (IDE) that catches all the mistakes and properly formats the code immediately. And my previous methods (e.g., typing into a text field) failed on both those fronts. Sure, I could use a JS code-editing library (I’ve done that). It works decently, but there’s always a catch or two that frustrated users (including me).

So this trend toward the better includes using a proper IDE to write the JS outside of a FileMaker field.

Working with a proper editor brings up a whole host of challenges; one has to actually pick a platform to use and then learn to use that platform. That takes time. I use VSCode for all my JS work now (and from that app will come screenshots). It’s complex and I don’t know all of it. But what I do know is that it makes writing JS so much easier. 

With this project, I set up a small web-based file structure inside a project folder. There are two simple files in which I do all my writing: index.html and index.js. That’s manageable. I can write my simple JavaScript code here and (eventually) get it into FileMaker.

index.html
index.html
index.js
index.js

I can’t get into all that VSCode does here in this post, but if you’re going to explore writing JavaScript, VSCode is a great choice to use. I’ll share more about how to use VSCode in the near future.

See the Fruits of My Coding

The FileMaker developer is used to seeing what she is developing appear or work before her eyes – if not in scripts, at least in what’s on the layout. So too must she be able to see the code work (or not) in the web viewer right away. Additionally, since we’re using the web viewer inside FIleMaker, it’s essential to get the JS code inside FileMaker as soon as possible.

Todd figured out a way to see the JavaScript work immediately in a FileMaker file’s web viewer object. We use it in our projects here at Proof+Geist, we used the technique in the add-ons, and I’m using it for this demonstration file.

Essentially, when I am developing the JavaScript code, I can run a development server that serves the code I’m writing. This development server is picked up by the web viewer and shows the results of my JavaScript coding. Whether the code works or doesn’t, I see how my code is turning out immediately.

By starting up a development server in VSCode, whatever I write in the code will be picked up by the web viewer.
The Development Server in Action

The mechanics behind this are a bit complex. It involves Node.js and some JavaScript libraries to run a development server. Hopefully, very soon, we will have a template project you can use that has all this already set up.  So be on the lookout for that.

Using the web viewer inside of FileMaker to render the code is one part of a better JavaScript development environment.

Using FileMaker Data

A hallmark of a better JavaScript development environment is to use real data inside FileMaker. Since we’re working inside a FileMaker app, it follows that we could use the data already in there. I don’t want to develop with fake data that may not have the same performance considerations as the real data. If my goal is to show 1000 records in a data table, then I want to make sure the whole process works with 1000 real records. 

In our development, we use data from FileMaker, and we do this using the Perform JavaScript in a Web Viewer step.

For this JSONata example, I’m using this script step to load data into the web viewer. The web viewer already contains the JS code, and the work will happen when it receives the JSON data and the query. Here’s my code.

This pattern is pretty standard:

  1. The web viewer on the layout is named. I write the name into a variable (line 1).
  2. I give the name to the global function inside the JavaScript in a variable (line 2).
  3. I pick up the query data in a variable (line 3).
  4. I pick up the JSON data in a variable (line 4).
  5. I then call the script step with the above pieces (line 8).

Notice that I’m pausing in line 7. In all of our work with the web viewer, we’ve found this to be essential. Since I’m using a new window (line 5) where the web viewer is located, I need to wait a small amount of time for the web viewer to load. And this has to happen so that the JS function “simpleQuery” is loaded and ready. Between Kevin and myself, we’ve tested it to be around ½ to 2 seconds. 

Getting the Data into the Web Viewer

The JavaScript function itself is pretty simple, but it has one part that is vital: it has to parse the incoming JSON data into something JavaScript can read. Line 4 here shows that I’m taking the JSON that comes in and parsing it.

The simple function called from FileMaker

We have template scripts written to help us remember the pattern. I use those all the time. 

Returning Results

Many times the point of a JavaScript library is to return results to FileMaker. This is the case in the work Kevin Frank and I did together. He found this cool library called JSONata that parsed JSON using a query language (one designed for this library). The idea is to pass the web viewer some JSON and a query and then get the result of the query back. So we have to work with FileMaker’s ability to get the result out.

In this example, we’re getting the results back in two ways: 1) we’re setting the data into a field, and 2) we’re getting the data back to use inside the script itself.

You can examine each script to see what they’re doing. They’re pretty simple:

Get Result Into the Field

This script simply shows what happens in the normal use case: One script calls the JavaScript. The JavaScript does the work and calls a FileMaker script – in this case, “Get Result” to return the result back to FileMaker. The original calling script finishes its run before the “Get Result” function runs. And that’s a fine progress of steps. The callback script gets the result and places the result into a field. End scene.

Get Result Into the Script

This script is built differently and uses the newer FileMaker.PerformScriptWithOption() function (documented here). In this case, I want to use the result in the original script. So I call this the function simpleQueryInScript(). The function processes the JSon using the query and calls back to FileMaker a script called “Get Result In Script”. This script interrupts the original script, gets the result from the JS and, in this case, sends it back to the original script.

I know this is a lot to take in, so study the scripting and examine the JS code provided here and see how it all works together.

This is a better environment for JavaScript in FileMaker development. It’s pretty close to all we can do to make it easy enough to write JS and see it render out in the web viewer while developing.

One more thing

We’ve been talking here about writing JavaScript. But there’s one more step: actually using the code you’ve written in an actual production. Don’t worry. We’ve got that covered. After I’ve finished with the code, I can run a small command and the JavaScript is put into the correct field inside of the app for the web viewer to pick up.

Uploading new code to FileMaker

Onward

Finding a better JavaScript development environment for FileMaker has been something we’ve explored for many years. We’re interested in making using JavaScript even more accessible by providing easy tools to get the job done. This FileMaker 19 + JSONATA exercise gave me the opportunity to flesh out what is really necessary to easily develop the code. Thank you to Kevin Frank of FileMaker Hacks for his proposal, his collaboration, and his support.

We’re not done; in future posts, we can point out how we work with VSCode and other tools to make this work.

If you are interested in working more with JavaScript in this better environment, let me know (jeremy.brown@proofgeist.com). If there’s enough interest, we can provide some training around this environment set-up and use.

The demo file is found here and at Kevin’s site.

FileMaker DevCon 2019 is done, over, kaput. The FileMaker & JavaScript training session we led during the conference brought over 100 people together to learn the basics of JavaScript inside of FIleMaker. It was a long day of learning and stumbling and success, and many of the attendees found a lot of value in it.

But it was only six hours. It went fast–probably three hours in total. Also a lot of people couldn’t attend. That was too bad.

Never fear: We’ve spent the last month redoing the entire session. We’ve put together countless videos that walk through almost every part of the session (I did skip some of the mistakes I made during the actual training session 🙂 I did make some new ones. Don’t worry. ). Anyone now can ‘attend’ the session by reviewing the following pages and information and following the videos and downloading the playground file.. This is good. There are videos that describe what we did in the session (sans the mistakes).

You can now watch the FileMaker and JavaScript training session at your leisure. You can rewind, fast forward, skip, and pause the videos as you work through the examples. Isn’t that awesome?

You can view the entire syllabus here as well as get the training session files. And here’s the details about each of the groups of videos.

The Basics of JavaScript (inside FileMaker)

There are 27 different exercises in the JSPlayground file to learn some JavaScript. This wasn’t a masters course in JavaScript, but the exercises that we went through represent the type of JavaScript that we might use in FileMaker.

Go through the exercises, follow along with us as we explore some JavaScript.

Oh, and there’s plenty of resources available in the file. Review this video to learn more about the JS Playground file.

Setting up an Integration

In the next section of the training session we worked on integrations. We explored how to take a JavaScript library and set it up to work with FileMaker data. We also customized the Integrations.

We spent our time on C3 JS and the DataTables library. It was a good time, and we walked away with some good sense of how to work with any JavaScript library.

Work with the FM WebViewer Bridge

In the final hours of the session (we were pretty brain-shot), we took a look at how to work with the FileMaker WebViewer Bridge. We saved the best for last. The functionality of this API works like magic and solves a lot of web viewer problems.

We spent our time working with DataTables and the C3 Charting library (yes, the same ones as before).

We did, however, start by looking at a cool progress bar.

In these videos we explored how to write FileMaker scripts that trigger JavaScript functions which call the library’s API methods to change the web viewer’s state without the refresh.

You can also get to the DataTables and the C3 examples we used with the Bridge

A Few More Notes

  • You need to download the FileMaker and JavaScript Training Session materials. You can find those here.
  • As you work through the videos you might have questions. Please reach out at support@geistinteractive.com and we’ll be glad to help you through what you need.
  • We are thinking of offering a webinar where we can work together on some of the items from the training session. Please let us know if that would be useful to you.

Virtual FileMaker and JavaScript Training Session

Have fun. Let these videos help you pretend you attended the FileMaker and JavaScript training session. Explore FileMaker and JavaScript. Explore and see the power of JS in FileMaker (JavaScript is, of course, native to FileMaker). It is completely possible for you to learn and use JavaScript. So come along with us, will yah?

At FileMaker DevCon 2019, I led over one hundred FileMaker developers in six hours of learning and working with JavaScript. It was a good day. We learned a lot. We made lots of mistakes. We fixed those mistakes. We felt pangs of frustration with the web viewer object. And we shouted with satisfaction when we got the web viewer to render our chart or datatable. In those six hours, however, we had to gloss over a few things. I intend to double back and talk in detail that which I blew right by to give all attendees the fullest experience. So here I’ll discuss how to extract and use the FM Web Viewer Bridge code and scripts from the JSPlayground file to your own.

One note: If you didn’t attend the session, feel free to participate in this post and video. There’s a lot in this video I’ve skipped over. But never fear: through future videos and webinars, I’ll retread what we did in the DevCon session.

Extracting the FM Web Viewer Bridge code

Working with the FileMaker Web Viewer Bridge was sort of the culmination of the JS training 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 to this later in another video.)

But we worked with the Bridge API within the context of the JSPlayground2019 file. Which is fun to play in, but hardly useful for production custom apps. So here’s how to extract the FM Web Viewer Bridge code into your own file. Follow along in the video. I’ve also written down the steps below. It’s pretty simple to do, and once you’ve done so you can use that first extraction in all your projects going forward. Let’s dive in.

Video Explanation

(15 minutes)

Written Explanation

Okay. Here are the steps you need to follow to extract the C3 chart with the bridge functionality out of your Playground file.

Export the Code

Export the code we wrote using the red Export button on the top right of the JSPlayground.fmp12 file. This exports this single record and all its code into a .fmp12 file to your desktop.

In this file, there’s an HTML_Calc field, but it is a text field. You can update it to be a calc field so that you can continue to tweak the JS code and have the web viewer grab the latest code. Here’s the code for the HTML_Calc field:

Substitute ( Code_HTML ; 
 ["__Script__" ; Code_Script];
 ["__CSS__" ; Code_CSS];
 ["__Data__" ; Code_Data] ; 
 ["__Library__" ; Code_Library] ; 
 ["__Extension__" ; Code_Extension1] ; 
 ["__D3__" ; Code_D3] ; 
 ["__FileName__" ; Get(FileName)] 
  )

Set up the Web Viewer

Set up a web viewer object on any layout. It really doesn’t matter the layout since you’re going to use a script to load the code into the web viewer. In the example, I just use the base table. Clear out all the checkboxes of the web viewer object set up except the “Allow Interaction . . . ” one (the first one). And finally name the object in the inspector. I called mine “BridgeWeb”. But that can be changed and updated in the scripting.

Custom Function

There is one small custom function, RandomNumber, that I used in the CreateColors script to pick two random colors from a list. Use it or not.

Windows Users Only

If you’re on Windows, or if any of your clients that will use this chart are on Windows, you need to add one more field to the table of the context that the web viewer object is on. Add any text field–I call mine ‘CopyPasteTarget’– and set the field to the right off the layout. Name it “CopyPasteField”. This will only be used when the FM WebViewer Bridge API is working with a hash (the URL) that is more than 2000 characters. It’s just necessary. :/

Copy / Paste Scripts

The next step is to copy and paste the necessary scripts into your file. If you wrote the C3 chart scripts, then you’ll copy those along with the scripts that runs the FM Web Viewer Bridge API. Select each of these, then copy them. Finally paste them into your file. If you do it that way, you’ll get no broken script references.

Here’s the full list:

  1. Load Bridge Example: this is the script that loads the code from the HTML_Calc field into the web viewer. Adjust this as you deem necessary, changing contexts to get to the layout with the web viewer. Here’s one place you need to update the web viewer’s name if you changed it.
  2. C3 Chart Folder: These are the scripts we wrote in the session. Copy the entire.
  3. FM WebViewer Bridge folder: Some of these scripts we’ll keep and some we’ll delete once the folder is in our file.

Copy all of these scripts/folders at one time and paste them into your file at one time. That will prevent any broken script references from showing up.

There will be a few errors; most of these are just broken field references. As you paste the scripts in, each script with an error will open in the Script Workspace. Go through each of these and fix what’s highlighted in red.

Delete Some Scripts

We don’t need all the scripts in the FM Web Viewer Bridge folder. Here’s a list of the scripts you can delete.

  1. ClickOn
  2. Inlined
  3. All the “Set ENV” scripts
  4. Compile URL Copy
  5. IsWebViewer Loading
  6. Close Web
  7. Generate JSON object

As you delete them, test to make sure you haven’t broken anything. To be super-sure, use FMPerception to find unreferenced Scripts.

Complete

After the above steps, you should be complete. You’ve successfully extracted the FM Web Viewer Bridge Code. The scripts and the functionality is copied from the JSPlayground file to your own custom app. From here you can use your file as a template.

If you do implement more than one bridge set up in your app, simply copy over that integration’s scripts. You shouldn’t have to recopy the Bridge scripts. It should be ready to go.

On Going

In the near future, we will continue our study of FileMaker & JavaScript. If you attended the session, I’ll have more videos and posts regarding stuff I had to gloss over. If you didn’t attend, I can lead you on from the beginning. Stay tuned for the plans we have.

Okay. Here’s the file

I planned on not uploading the file that I demoed here, but decided to reverse course. The more people that see and experience JavaScript in FileMaker, the better. So here’s the file. Pick it apart. And feel free to let me know if you have questions about it!

Proof and Northeast Database Solutions are excited to announce the launch of the first official community edition version of fmEZcharts!

fmEZcharts is a chart and dashboard tool for Claris FileMaker that allows for the quick and easy creation of JavaScript or HTML chart components (even if you don’t know anything about JavaScript or HTML). Over a year in the making, the newest version offers a tighter, cleaner look and feel, with improved functionality and usability. It includes new features like the ability to pick themes, colors, and data sets, as well as a larger selection of ready-to-go charts.

fmEZcharts is available to download for free at fmezcharts.com. Give it a try and let us know what you think!

Email: support@fmezcharts.com

https://vimeo.com/352142436

My username on the FileMaker community is “jeremy_fm_js”, and I’ve been known to advocate using JavaScript in FileMaker for a few years now. It might be interesting to be typecast into ‘the guy that always talks JavaScript’ (I don’t always recommend JS in my posts in the community), but I advocate for many good reasons. Some of them are reasons I’ve stated before, but also, there’s a few new ones I’ve thought of in the past year 🙂 If you need an escape hatch–this is, if you need to build an interface that is more interactive than we can do using ‘idiomatic‘ FileMaker–we can consider JavaScript, and we can consider learning the language. To help you learn JavaScript, JavaScript is part of FileMaker DevCon.

Why JavaScript?

The answer to this question is: why not JavaScript? There’s a lot of innovation we can bring to custom apps using the language native to FileMaker. JavaScript and JavaScript libraries brings thousands of testers to its foundation. I’ve written about all this before.

More reasons

FileMaker itself seems to be giving some weight to JavaScript in the platform (the entire platform, of course). There are two pieces of evidence. First, exploring JavaScript, for the third consecutive year, is part of FileMaker DevCon, the FileMaker conference. Along with APIs and Zapier and microservices, attendees will have the chance to see and experience what JavaScript can do in our apps.

Secondly, JavaScript is specifically mentioned in the product roadmap. In the past it’s been rare to see something so ‘outside’ of FileMaker be mentioned in the FileMaker plans, but there it is. So FileMaker, Inc, and my friends in the product-development team, must have some special plans for it.

The roadmap states: “Within a web viewer, directly call JavaScript from FileMaker scripts and vice versa.” That’s a very amazing idea. We will be able to solve certain web viewer problems with this functionality and give more control to FileMaker interacting with the JavaScript code.

JavaScript at DevCon

All day pre-conference training

This year I have the honor of leading folks in a full-day training of FileMaker & JavaScript. We will work together for six hours to talk about the following objectives and concrete activities.

Learn the basics of the JavaScript language

We’ll work together on exercises that teach us the basics of the language. We’ll talk about JavaScript concepts, and we’ll connect what’s true about JavaScript with what we already know in FileMaker.

Each exercise comes with one or more extra practices. We’ll do those to drive the point home.

Identify the peculiarities of the web viewer object on different devices

The web viewer object in FileMaker is powerful, but it is quirky. We have to understand its needs for each device, so as we practice and exercise, we’ll talk about how the web viewer works differently in different operating systems.

Integrate JavaScript libraries into any custom app

The fun of this day will be to spend time putting charts or data tables or any number of other libraries into our apps. We’ll learn how to do this from scratch. We’ll also review the tools out there that make this part very easy.

Just so you know: In order to work with libraries, we need to know a little JavaScript. We can’t run until we learn to walk.

Learn to communicate between JavaScript and FileMaker easily

The FM WebViewer Bridge framework is an important last-piece of the puzzle. It solves quite a few problems when working with the web viewer, and it provides a less jarring experience for your users. We’ll examine how this framework works.

We will work through examples and practices to learn more about how we can use JavaScript, and it will be a productive day. Attendees will learn a lot about how to use the language. We won’t be JS experts, but we will at least know a bit more of our way around its use in FileMaker. I have two ultimate soft goals:

To be comfortable enough with JavaScript we can look a JavaScript library in the face and not run away screaming in terror.

and

To expand our horizons of what is possible with FileMaker and JavaScript.

The six hours will be more than enough time to get our feet wet. If you haven’t signed up yet for this training time, I encourage you to give it a consideration. JavaScript brings to our fingers much power, and this session can help you see how to harness that power.

Discussions throughout the week

I wish to continue the JavaScript discussion well after the training session ends (after we’ve had a chance to recover from the workshop). Last year I was available to talk shop and sat with a few folks to talk one-on-one about how to integrate a chart or a data table into their in-production apps. That was a blast. So this year I wish to continue that. While at the booth or at food time or in the hallway, I’ll be available to talk with folks about their use of JS in their apps. So feel free to find some time with me and we can continue to discuss this innovative tool.

JavaScript after DevCon

The fun doesn’t end when FileMaker DevCon 2019 ends. Oh no. Energized from that experience, I’ll continue to talk about JavaScript and FileMaker. I’d love to do a follow up training session with interested folks to continue to learn more about the language and how to use it in FileMaker. So stay tuned to this blog and our Twitter page for more information.

Preparing for DevCon

If you do plan (or are thinking about) on joining me for FileMaker & JavaScript, please take a moment to download the file (below) and test your setup (computer, browser security settings, FileMaker version etc) to see if all will go well with your time. Basically click some buttons and confirm you see the web viewer user interface and interactions. Those running macOS will be fine. Windows users should really test it out.

I want you to be successful in the session. The file here contains a small sample of what we will do; all the items you’ll test here we want to make sure work. If you download the file and run thru the tests and all is good, you’ll have no issues with the work we do during the training. If you do have issues, please reach out to me at support@geistinteractive.com and we can work on finding a solution so that you can attend and learn and exercise your innovative spirit.

Don’t worry if your copy ‘fails’. I have a plan in case you can’t view the C3Chart or the DataTables or the PivotTable. The only extremely-vital one is the Code Editor test.

See yah in just a month! And get ready for JavaScript at FileMaker DevCon.

Downloads

The following list of downloads reflects what we did during the FileMaker & JavaScript session. More is coming soon.

JS Test File: test your machine to be ready for the training

Session Slides: The slides we used to talk about JavaScript and FileMaker and the web viewer.

To view all the resources we used and to view tutorial videos walking through each exercise we did during the session, go to this page.

Last week we introduced a game-changing app in the FileMaker & JavaScript space. WidgetStudio makes it so simple to add simple or FileMaker web viewer widgets to your custom app. From pivot tables to charts, WidgetStudio allows you to find or create, customize, and deploy the widget in a matter of minutes.

Find widgets

The WidgetStudio demo has three FileMaker web viewer widgets included that you can use to play with and see how the app works. But beyond that, there are more than ten other widgets that are available for WidgetStudio users (licensed and demo users) to view and customize.

Licensed users can deploy widgets from the library, but everyone can see what we have.

Here’s what we have so far.

More widgets on the way!

These eleven widgets are available now for review and deployment (with a licensed copy of WidgetStudio), but we won’t stop here. Over the coming weeks and for the foreseeable future, we plan to release widgets through the repository. So stay tuned to Geist Interactive and WidgetStudio on Twitter to get the latest.

If you have an idea for any FileMaker web viewer widgets, be it a JavaScript library or just a FileMaker use case, send it our way and we’ll try to create that widget.

Additionally if you want to make your own widgets, you can. Feel free to submit the widget to us to add to the repository.

WidgetStudio is a tool

Like a hammer, you go out and buy the hammer. You pay for the tool. What you build with it is up to you, and the hammer store doesn’t charge you for what you build. Likewise, WidgetStudio is a tool that has an annual license. How you use WidgetStudio is up to you; there is no additional charge for use of the widgets.

Use FileMaker web viewer widgets everywhere

WidgetStudio allows you to distribute FileMaker web viewer widgets in a few ways.

  • You can share a widget exported from WidgetStudio (as a .json file) with another developer.
  • You can deploy a widget using an embedded web viewer or through a script.

These royalty-free methods of distribution are completely independent of WidgetStudio. They will work regardless of WidgetStudio’s presence or active status. The widgets will continue to work in your system systems.

License options

We provide four license options of WidgetStudio. These licenses have everything to do with the number of computers that uses WidgetStudio. No one who simply uses a deployed widget in a custom app needs a license.

The power of FileMaker web viewer widgets

WidgetStudio gives any FileMaker developer access to powerful widgets that can be used in any custom app. We use them. Join us and check out the demo of WidgetStudio to give this power a try.

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.

Integrating JavaScript libraries is becoming an obsession of mine. I spend my half free time searching for new integrations that might work in FileMaker, and the other half implementing those. I look for JS libraries that are accessible and ones that provide functionality that might be used in a custom app. I think that this next one, a FileMaker Audio Player can be very useful. Let’s take a look how to integrate this simple library.

Feel free to download the sample files here.

This video describes how I set this up. It’s shorter, about 35 minutes. As is usual, I make some mistakes along the way.

Key Points

Setting up the FileMaker audio player

Just like the other videos, we set up an HTML table in the normal way. We’ve got fields that will hold each text file: the HTML, the CSS, and the JavaScript files.

It’s common for me to do this since this allows the JavaScript to work offline. All the code needed for the library, in this case the FileMaker Audio Player, to work is in a record in a table. The web viewer can work with the text in each field.

Also, this structure closely resembles an actual web page construction. A web designer will create one file for each CSS or JavaScript library. Then, in the HTML document, she will link those together. We’re doing roughly the same thing here. We’ve got placeholder text in the HTML field. FileMaker’s calculation engine will, in the HTML_Calc field, do the work of placing the code inside the HTML page at runtime. And the web viewer will work.

The placeholder text set up resembles how web designers structure their page.

The placeholder text set up resembles how web designers structure their page.

There’s another way to work with libraries: our Web Viewer Bridge set up. That’s a free tool you can use. We’ll study it in an upcoming blog and video (more likely a few of those).

The Audio

The FileMaker Audio player can play an actual audio file that is stored in a container field. The library plays it in the web viewer. The web viewer, however, needs the audio file in base64 encoded form, so we have to base64 encode the file in another field or on the fly.

In the video I use the old FileMaker function Base64Encode. This works, but it places a return character after so many characters. And those characters mess up the audio file. I should have used the new one: Base64EncodeRFC which accepts a parameter in the form of a number telling the function to not insert any return characters.

Once the audio is encoded, it is placed in the Data field and used in the JS_Function field in a function there.

The possibilities

This library does one thing: it plays audio showing that audio’s wave form in a web viewer. It does have a few possibilities. Here are some of the options you can update:

  • The color of the wave form
  • The color of the progress wave form
  • The color of the current-time indicator
  • The height of the wave form
  • The playback speed

There’s a lot you can do with this.

Additionally, you can add buttons that do more, that control the wave form. In my final example, I added a button to change the playback speed and a slider to adjust the volume. These two are in addition to the standard play/pause.

Use your JavaScript skills

Finally, I put together JavaScript functions to make the user experience better. For example, the button that plays or pauses the audio has text that changes. If the music is not playing, the button says “Play”. When I click on the button and the music begins to play, the button’s text changes to “Pause”.

This type of functionality can only be done by actually using JavaScript to change the text. During DevCon 2018, we spent some time learning pur JavaScript. Though it wasn’t as exciting as the integrations, learning JS is essential to actually using the libraries. I couldn’t change the text from “play” to “pause” without knowing some JavaScript.

Try out the FileMaker Audio Player

Give this one a try. Even if you’ve no immediate use for it, it’s worth the time to practice your integration skills.

JavaScript libraries bring additional and deeper functionality to a FileMaker custom app that are not yet available inside the platform. One widget that I’ve used occasionally in the past was a Date Range Picker. This particular integration is pretty simple to set up and to use. It allows us to add a picker to our custom app that is customized to our locale and easily sends the selected dates back to FileMaker. So let’s study how to work with this FileMaker Date Range Picker, just as we’ve done now with DataTables and C3 Charts.

In this post, I’ll summarize the key points of the video and point out the sections of the 45 minute tutorial. Also in this video, we examine a few ways to spread this integration to any part of your custom app. It’s the first time we’ve talked about this specifically, but I’ll bring it up in a future video.

Here’s the file if you want to follow along and build a FileMaker Date Range Picker.

Sections

The video is 45 minutes. I walk through how to set it up, make a few mistakes along the way, but fix those in time. Here’s the breakdown:

  • 00:00–Intro and integration
  • 20:41–The Callback function: Sending the dates to FileMaker
  • 31:30–Setting up Options: changing how the date picker functions.
  • 38:57–Using in FileMaker: strategies for spreading the integration to many parts
  • 44:57–The Finishing Touches: Causing the picker to appear when the window loads

Key Points

Setting up the FileMaker date range picker

Here we go through our normal process of setting up a table to hold all the libraries, the HTML document, and the JavaScript function. We don’t need a data field since this is just a widget. I’m considering a sort of ‘generator‘ to help me create the fields and tables we need so that we don’t have to go through this tedious process every time. (FYI: There is another way that we’ll get into in an upcoming movie that deals with our Web Viewer Bridge Library).

We also set up the layout to be accommodating for us to enter and edit the libraries.

Interesting details

This integration came with a bunch of interesting little points that we may not have addressed before.

  • We built an input text box in the web viewer, and we added a font-awesome icon just to the right of the input box.
  • We used our knowledge of JavaScript to change the code just a little bit. That was fun.
  • The JQuery function $ (it really is a function) applies a date picker method to the input text box.
  • That date picker method: datepicker() is something the author of the library built for us. It is somewhere in the DatePicker library. We don’t have to worry about it. He’s tested it many times. It works very well. It’s like us calling a script from a separate file. We don’t have to understand it, we can just use it.

    A picture of the FIleMaker date range picker.

    There are options galore!

  • There are many options, and we could spend hours configuring this widget to our needs (for fun, not because we have to build each option).
  • What’s cool about the options is that one line of code:  “showdropdowns: true” is all it takes to add a month and year dropdown that updates the calendar to the widget. Or this one: “timePicker: true” draws and adds the time-picker functionality. Wow.
  • the Moment.js library handles date and time formatting for me. I don’t have to do any conversion of the dates when they’re brought into FileMaker. This is a great library I wish I could use more in everyday FileMaker work.

I’m only human

Throughout this video, I made a few mistakes. Here is a rundown of what I did, which happen to be the common errors anyone could make:

  • I forgot a comma in between object properties.
  • I would sometimes forget the closing parenthesis or bracket. This vexed me a few times. I mention in the video that it is best practice to write the opening and closing brackets or parentheses at the same time before filling in the function or options. You are wise to get the hamburger buns before putting in the meat and toppings.
  • Sometimes I put options in the incorrect place. The solution with this comes simply by understanding the structure of the JavaScript.
  • The order in which the libraries loads matters. In this case, the JQuery library needs to be loaded before the DatePicker library. And both of these are required for the actual function to work.
  • The Substitute Function in FileMaker is case-sensitive. “**JQuery**” is not the same as “**jQuery**”. So placeholder text and the text inside the substitute function must be the same.

A picture of my errors

Applying the FileMaker date range picker anywhere

We also briefly touched two ways to allow this to be used anywhere in your custom app. Since we’re dealing with fields in a table, we either have to establish a relationship or load the data into global variables or fields with global storage (global fields). I built this both ways. As FileMaker developers, we can understand the pros and cons of each way, but I’ll bring that up in a future video.

This is a good and simple widget. It is powerful and easy enough to use in any custom app. Give it a try. If nothing else, it’s good practice.

Download the files that I used and see how satisfying it is to build a fully-functional FileMaker date range picker widget. I’ll continue demonstrating integrations from my DevCon 2018 session. And if you haven’t yet, please join our FM/JS Slack channel.

If you want rich interactive charts in your FileMaker app, you are going to need to go beyond the built-in FileMaker charts. Luckily, the FileMaker Workplace Innovation Platform has escape hatches you can use to get just about any job done. In this post and video, I am going to show you how to make FileMaker Interactive Charts with the maybe the most powerful escape hatch in the professional Filemaker developer’s toolkit, JavaScript!

Why Not Just Use the Built-In Charts?

The built-in charts that come with FileMaker out of the box are fine.  They work well and look pretty good. But they are static. There is no animation and they don’t respond to clicks. There isn’t any way to drill down into data sets or otherwise explore the visualizations. Also, data visualization goes way beyond whats provided by the built-in charts.  If we need that extra innovative experience in our apps then we reach for the JS.

FileMaker Interactive Charts

We’ll need some JavaScript and a charting library. We’ll use C3 for this demo. The C3 Charting library is a built on top of D3 the most popular data visualization JavaScript library on the planet. It provides a lot of functionality and a lot of customization possibilities. Take a look at this video to see how to set up the library in your custom app

Oh, and download the files here to follow along.

FileMaker C3Charting

The video is about 45 minutes long. Here’s a breakdown of the sections:

  • 00:00–Setup
  • 17:40–Customization
  • 31:33–Handling Clicks
  • 40:41–Dashboard Possibilities

Some notes

Completely customizable

FileMaker Interactive Charting gives us complete control of the chart. Here’s a partial list of elements we can control:

  • The type of chart
  • Displaying two types of charts in the same graph.
  • The labels and their format
  • The x-axis categories, their display format, and the number of ticks.
  • The y-axis placement (left, right, or both)
  • What happens when you click on or hover over a data point.
  • The colors of each line or bar or pie segment
  • Whether or not grid lines are drawn in the graph

It’s incredible what we can do, and it is fairly easy to set up.

Takes some time

FileMaker C3Charting does take some time to set up, but it gets easier the more times you do it. There’s the data structure and the library files code copying. You have to write in the customization you want and so on. There’s a lot to do, but that’s okay. It is worth the time to get the chart exactly how your client wishes it to be.

FileMaker Interactive Charts

Dashboard possibilities

With a Web Viewer and with this charting library, you can set up a dashboard. More than one chart can be visible, each chart having different properties. With this library, a dashboard is easy to generate.

We will revisit this

FileMaker Interactive Charts requires a lot more discussion, so don’t think we are done with this discussion. In a future video, we’ll explore how to use JSON as the data that drives the chart.

Onward

The C3Charting JavaScript library is great Pro tool to add to our tool box when we need to go out that escape hatch and get the job done.  In this case, we made some awesome FileMaker Interactive Charts. We’ll continue our study of JavaScript that we began at DevCon. Please join us in the SLACK channel, and we’ll talk about these. And stay tuned to our site for more integration videos.