[Authored by Alex G]
There are many cases where FileMaker’s scripting isn’t always the best tool for the job and where a language like Ruby can bring a lot of power to your FileMaker development. The following is a description of a simple technique for using ruby scripts from within a FileMaker solution without the use of a plugin. I’ve found this technique useful for employing regular expressions for complex text parsing, making web requests to work with web APIs, and for parsing and generating XML and other serialized data structures. Ruby has a wealth of great libraries for doing anything you can imagine and is just plain fun to write.
How It Works
Ruby code stored in a FileMaker global is saved as a ruby executable using AppleScript. AppleScript then cleans up the code’s formatting, replacing FileMaker’s line breaks with unix style line feeds. A shell script is then executed running the ruby script with any specified parameters. And finally, the stdout results are stored back into FileMaker by way of AppleScript.
Caveats
There are a number of caveats with this technique. The first and most obvious is that this is a Mac only solution, i.e. AppleScript = Mac. But another biggie is performance. There is considerable overhead in compiling and running AppleScript, pulling and pushing data to FileMaker, writing the executable, and then running the script. All these steps makes this technique unsuitable for repetitive operations.
This technique also lacks the ability to capture errors in the ruby runtime. This could effectively be handled by wrapping the ruby execution in an AppleScript try statement to capture errors, but would make FileMaker side error capture of the applescript statement slightly more complex.
The Examples
Example File: Ruby_Execution.fp7
Attached to this post is a FileMaker file that demonstrates the technique and that can be used to write and execute ruby scripts of your own. Also included are a number of example scripts that demonstrate passing parameters, using regular expressions, making http requests, making multi-threaded web requests, parsing xml, and more.
Script parameters are passed as command line arguments and are available in the ARGV array inside the script. In most of the examples I make use of the getoptlong ruby library to handle passing parameters by name. Here is how that is handled in the “Update my twitter status ( user ; pass ; status )” script.
require ‘getoptlong’
opts = GetoptLong.new(
[ “–user”, “-u”, GetoptLong::REQUIRED_ARGUMENT ],
[ “–password”, “-p”, GetoptLong::REQUIRED_ARGUMENT ],
[ “–status”, “-s”, GetoptLong::REQUIRED_ARGUMENT ]
)
user, password, status = ”
opts.each do |opt, arg|
case opt
when ‘–user’
user = arg
when ‘–password’
password = arg
when ‘–status’
status = arg
end
end
After we properly handle parameter passing we only need the following lines, which employ ActiveResource, to update your twitter status.
class Twitter < ActiveResource::Base self.site = “http://twitter.com/” self.element_name = ‘status’ self.timeout = 5 end Twitter.user = user Twitter.password = password Twitter.post(:update, :status => status)
