Using the Webviewer is a promising approach for countless specific cases, which includes:
- custom made GUIs
- navigational elements
- interactive graphics
- complex calculations that are going beyond FileMakers own calculation capabilities
Although there are some hacks and workarounds to provide basic interaction between the Web viewer and FileMaker Scripts, every single approach that has been found so far has a lot of pitfalls, restrictions and there is no technique today that will run on all plattforms (Desktop, iOS, Webdirect).
It is quite obvious that there exists a missing link that prevents the web technologies, living inside the Web viewer, to unfold their full potential in a cooperative use with native FileMaker techniques.
If there was a clearly definied API to the Web viewer that would allow secure, flexible and robust communication between the Web viewer and FileMaker Scripts in both directions it would immediately open up a whole new world of possibilities and use cases.
HOW COULD THIS BE IMPLEMENTED:
- WVAPI.runJSscript (with optional Parameter) –> catched by JS listener inside Webviewer to run JS Script
- WVAPI.runFMscript (with optional Parameter) –> called by JS function inside Webviewer to run Script on FileMaker side
- WVAPI.sendFieldContentsToFM (with Parameters) –> called by JS function inside Webviewer to populate FileMaker fields with content
Parameters would best be defined and passed as JSON-strings for maximum flexibility.
I could imagine that those event handlers are somehow injected/registered into every Web viewer behind the scenes as a given standard set like "onload()" or similar DOM events.
(@FileMaker engineers: You will certainly find some naming scheme that will best fit your existing conventions)
WHAT ABOUT SECURITY CONCERNS?
Triggering native FileMaker Scripts and Fields from an external source raises security questions.
The described approach should provide a basic authentification scheme for all API calls. Everything else that happens native on the FileMaker side would be controlled by given account rights anyway.
A simple but effective approach to API authentification between FileMaker and Web viewer could be the use of Session tokens.
On the FileMaker side it would need a Script step "setWVAPISessionToken [TokenString]. With this step an internal value is set before any API call could take place from within the Web viewer.
On the WebViewer side every API call must then provide that predefined Session token string as a required parameter.
FileMakers internal Scripting-API for the Web viewer would then compare the predefined stored value with the required API parameter and only continues to run the API call, if both values are identical. Think of it as a kind of passphrase that is required to make an API call.
Providing a Script step to set the session token instead of building it into an own FileMaker dialog setting would allow flexible authentification designs that are controlled by the developer of the FileMaker solution. (e.g. global fixed passphrase vs. User account based passphrase vs. Session based passphrase, etc.).
Hopefully it is possible to build up a simple, robust, flexible and secure Web viewer API without breaking other technical conventions inside FileMaker.
The described solution may be an elegant way to close the gap by just depending on a few little additions to existing elements.
For a minimal effort there would be some rich and very potential possibilities in reward.