Using Dynamic Script Triggers in FileMaker Go
What?
It was a couple years ago that I was introduced to dynamic script triggering in a video by Matt Petrowski. The basic premise is that you maintain a table with the names of scripts and a label that is presented in a portal view on a layout. You attach a FileMaker script to an object in that portal and triggering that button would in turn trigger a target script specified by the record clicked. The concept was powerful and uncluttered the interface by keeping all the buttons in a single portal. There is a catch; it requires a plugin and even with the advent of FileMaker 12, that dependency has not gone away.
With a strong emphasis on mobile computing, the inability to use plugins in FileMaker Go broke this paradigm. Or did it? While you cannot use a plugin on FileMaker Go, you can trigger scripts through the use of the FMP protocol specified in a url. You may have seen examples of this before. A link in an email opens a solution on the local device in Go. But, in this example, we are triggering scripts directly in the solution by making use of the open URL script and the FMGo Script protocol.
Where?
Navigation buttons are prime candidate for this type of use though you don’t have to limit yourself to just navigation. On an iPhone, users are accustomed to looking near the bottom of the screen for some type of action button that clues them in as to what actions can be performed in that given context. Having 4 to 5 iconic buttons at the bottom that are context aware saves you time.
When?
There is a balance between development speed and complexity that the developer should weigh. For simplistic solutions that have only minimal functionality, this approach may be overkill. But it doesn’t take very much before added functionality begins to exponentially add time when developing interfaces with buttons. You won’t get out of defining scripts unless the button has only a single function.
Most solutions all require some basics: navigation, create new record, delete record, search, save, edit, etc. Let’s say your solution has 2 different tables (for example, customers and orders). You could define those buttons as single actions, two for go to layout (customers, order), one for create new record, one for delete record, one for Enter Find Mode. You just defined 5 buttons! This is okay if your solution was that simple. I never have life that easy any more. My client wants to search for the customer then create the estimate using that customer. Well, now I’m defining a script to attach to that button–and so it goes.
Now by using an “actions” pallet, you add a table to manage the scripts and parameters you need to execute and the “context” in which they show up. Define one button and put it in a portal and you are done. Now copy and paste that portal in every layout you need it. As long as you maintain a valid relationship from that context to the actions pallet, it “just works.”
Why?
It’s simple. You want to be able to define code once and re-use it. I like the idea of copy/paste and that’s exactly what I do with this code. Copy a table, copy a portal with a button definition, paste that into my new solution. A couple tweaks and I’m done. No more guessing at where to fit in one more button on a layout, it was already there.
How?
Download the FileMaker Go demo file and full PDF article to learn more!
About Excelisys, Inc.: Founded in 2001, Excelisys (www.excelisys.com) is an international organization specializing in building, supporting, consulting, migrating, upgrading, tweaking, fixing, and integrating quality custom FileMaker Pro, FileMaker Go, MySQL, PostgreSQL, QuickBooks-FileMaker Pro Integration, Excel to FileMaker Pro conversions, iPhone and iPad integration, and other various database technologies and frameworks for web, mobile, and desktop deployment strategies. Contact Excelisys for a free estimate on your next project 866-592-9235.
Leave A Comment