The Original FileMaker Community
Business Templates - Demo Apps - Video Tutorials -Samples - Help - 46000 Member Forum

The Leading Filemaker Developer Tools

FMP URL and JavaScript Responsive Web Viewer Layouts – FileMaker Today

Get real time updates directly on you device, subscribe now.

With the release of FileMaker 13.0v2 came a huge boost to the usability of the FMP URL protocol – specifically that it can now be used in unhosted FileMaker Pro files. A number of developers have put out examples* showing some cool things that can be done with Web Viewers and the FMP URL, so I figured this would be a good time to resurrect the file I made a year ago.

Please see Responsive FileMaker Design & Web-Viewer Layouts ( the trailer ) for more details, the inspiration, and a screencast video showing how to use the file, etc.


There are still some issues that I wish were better dealt with when using these techniques, which is the main reason I never updated my demo file until now. My main frustration is that the protocol can only be used on a given computer in either FileMaker 12 *OR* 13, not both. So if your computer is set to use the FMP URL protocol with FileMaker 13 and you try to use an FMP URL in a database open in FileMaker 12 (or vice versa), it won’t work. It may try to open 13, but won’t have the context from which it was initially run. For Mac users, there is a downloadable preference pane that can be used to select the default application for the FMP URL, although this doesn’t remove the problem of 12 *or* 13. This problem also exists on Windows. I haven’t tested this, but maybe it can do something similar. Either way, it’s a real drag that we can’t just trust that a solution we build using Web Viewers and the FMP URL will work for all users — without the possibility that they may need to download & configure something just in order for it to work.</rant>

Demo = (a) Web Viewer interaction + (b) “Responsive”

As a brief review, there are two main components to this demo file:

  • It uses a Web Viewer, the FMP URL protocol and JavaScript to read from and push to the underlying FileMaker fields.

  • The layouts are “responsive”—using techniques from “Responsive Web Design“—which means a single layout adapts to screen sizes from iPhone (FMGo) to desktop.

These two components don’t need to go together, but it was really the “responsive” part that pushed me to experiment with all this in the first place.  However, since the FMP URL is the thing that’s changed with 13.0v2, that’s what I’m focusing on in this post.

Overview  (fmp:// URL, called by JavaScript, on Responsive ”Web-Viewer Layouts”)

The data-entry layouts contain only a Web Viewer.  The web viewer uses a Data URL that inserts the relevant field contents into <input> elements within an HTML <form> element (like a form you’d fill out on a website). As you navigate through the records, the Web Viewer is updated with the data of each record.

When you submit a change to the data — either via the Submit button or by hitting Return/Enter on a regular keyboard or touching “Go” on the iOS keyboard — JavaScript sends the contents of all fields, along with their respective field names, as a single parameter to an FMP URL that then calls a “PerformEdit” FileMaker script on that record. This FileMaker script in turn parses the parameter into name-value pairs (field name & field value) and then uses the Set Field By Name script step to update the record.

The JavaScript

NOTE: You do not need to understand or modify this JavaScript in order to incorporate these techniques into your database.

  var str = $('form').serialize();
  var encStr = encodeURIComponent(str);
  var replStr = encStr.replace(/%3D/g,':::').replace(/%26/g,'|||');
  $(this).attr('action', '" & FilePath_cf & "?script=PerformEdit&param=' + replStr );

Basically, when the form is submitted this grabs all of the field names and field contents and places them into one text string. It then encodes that string to be “URL-safe” and then replaces the specific “=” and “&” characters that define the key-value pairs in that encoded string with other text strings to make things easier on the FileMaker side

Here are the three versions of the string before it gets sent to FileMaker as the fmp:// parameter:

1) As captured via the jQuery serialize() method [ var str ] :


2) Having passed through the JavaScript encodeURIComponent() function [ var encStr ] :


3) And then swapping some strings via the JavaScript replace() method [ var replStr ] :


You can see in this last iteration, the ampersand character that divides the key-value pairs (as seen in the initial version of the string) has been replaced with “|||”, yet the ampersand entered in the Company field, “Doe & Doe”, retains its standard URLencoded string “%2526”.

The FileMaker Script

The FileMaker script first decodes the JavaScript-encoded string (step 2, above) via a custom function.  It then replaces all occurrences of “|||” (step 3) with pilcrows (¶) so that the one long text string becomes a list of key-value pairs, with the field name and the field value separated by the “:::” string.  The script then just loops through all these pairs, and uses the Set Field By Name script step to update all fields:

Set Variable [ $vals; Value:Substitute ( URLDecode_cf ( Get ( ScriptParameter ) ) ; "|||" ; "¶" ) ]

Set Variable [ $fieldCount; Value:ValueCount($vals) ]
Set Variable [ $i; Value:1 ]
Set Variable [ $error; Value:0 ]
Set Error Capture [ On ]
  Exit Loop If [ $i > $fieldCount ]
  Set Variable [ $parseKeyValuePair; Value:
    Let ( [
      _row = GetValue ( $vals ; $i ) ;
      _pos = Position ( _row ; ":::" ; 1 ; 1 ) ;
      $fieldName = Get( LayoutTableName ) & "::" & Left ( _row ; _pos - 1 ) ;
      $fieldValue = Substitute ( Middle ( _row ; _pos + 3 ; 9999 ) ; "+" ; " " )
    ] ; 
  Set Field By Name [ $fieldName; $fieldValue ]
  If [ Get ( LastError ) <> 0 ]
    Set Variable [ $error; Value:Get ( LastError ) ]
    Exit Loop If [ 1 ]
  End If
  Set Variable [ $i; Value:$i + 1 ]
End Loop
If [ not $error ]
  Commit Records/Requests
End If
Exit Script [ Result: $error ]

Using the demo;  Incorporating with your own data

The demo contains two separate layouts that both interact with the FileMaker data as described above:

  • A generic template layout, named “SomeLayout”, which any FileMaker user should be able to modify and use with their own data.  As demonstrated in the video on the original post, you only need to place the relevant fields onto a standard FileMaker layout (with the appropriate naming convention; in this demo it’s “SomeLayout_fields”) and the Web-Viewer layout will place all those fields automatically into the web form.

  • A “customized” layout which uses significantly more complex CSS, JavaScript and some HTML5 — to give an example of what could be possible for developers with more web development skills.

Both layouts are Responsive. And with rumors of a larger screen coming with the iPhone 6, this could be another good reason to use these techniques over separate layouts for each device/window size…



Download the Demo File

This is the same file from my original post; cleaned up a bit, unlocked, and still happily not perfect 🙂  

In fact, navigating records natively in FMGo13 now looks very odd in the “Customized” layout because of the slide effect — so I’d probably remove the Status Bar on a production file like this for FMGo.  Also,  Internet Explorer 9 does not support columns in CSS so on Windows with IE9, the template layout is always just one column. There are other options if you need to support IE9.

Get it zipped (.zip) or unzipped (.fmp12) (for FMGo)

And remember to check out my original post to see more of how to use this file.

Other possibilities…

There are a number of additional advantages to using “Web-Viewer layouts”.  Because the whole interface is essentially a web page, you could incorporate almost any web technologies into a Filemaker interface. Pretty much anything you’ve seen on the Web (specifically in Safari &/or Internet Explorer, since those are what run FM Web Viewers) could be brought into FileMaker.  Think of user-friendly web forms with instant field-validation, hints, “masks” that only allow the input of certain characters (e.g. ”(___) ___-____” for U.S.-type phone numbers, in which typing a letter character won’t even display), etc.

Also, because the styling of the layout is done via CSS in a text field, you could potentially open up modification of layouts to anyone with edit-access, including in FileMaker Go!

FileMaker 13 has brought in some great new web-like UI features such as hiding elements, popovers and slide controls, but there’s still plenty in the world of web design that can only be implemented in FileMaker via Web Viewers.  And now since 13.0v2, there’s very little reason (see Caveat, above) not to start implementing them now.

*Other FMP URL examples: 

& my “A web-like UI for DevCon2Go (2013)” from last year’s DevCon

Please add additional examples or resources in the comments.

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More