Web Development Archives

The State of FileMaker 13

April 17, 2014 by Kirk Bowman 14 Comments

If you are a customer or developer using FileMaker Pro, you probably know the latest version, FileMaker 13 was released in December 2013. I have not written about this release yet, because I wanted to reserve my comments until I had time to work with it. Now I have. So, what is the state of FileMaker 13?

First, let’s talk about what FileMaker is at the core. It is a client-server database platform for making custom business applications. For years, FileMaker has had a desktop application (FMPro) and a server application (FMS). Then recently, FMI added an iOS application (FMGo). So, now the “client” part of client-server includes the iPhone and iPad.

Web Publishing

Of course, FileMaker also has a web publishing component in the server application. Instant Web Publishing (retired in FileMaker 13), was designed to help a FileMaker developer with minimal web experience create web access to a FileMaker solution. Custom Web Publishing was intended for the traditional web developer who knows HTML, CSS, PHP, etc. to create custom web apps for a FileMaker backend.

In FileMaker 13, Instant Web Publishing was replaced with WebDirect. WebDirect is intended to bring the desktop experience of FileMaker Pro to the browser. WebDirect is a new technology, a 1.0 release. In some ways, it is similar to when FileMaker Go released. It is a new type of “client” except it does not require installing any software because it runs in the browser. As with FMGo, will require some time to mature and for developers to figure out best practices.

Client-Server

So, where does this leave us? I go back to what I said earlier. FileMaker is a client-server database platform for making custom business applications. Currently it has two rock-solid clients, desktop (FMPro) and iOS (FMGo). You could also consider Custom Web Publishing a third client except that it requires development skills outside the normal FileMaker toolbox.

FileMaker is not a true SaaS application. It requires a client on the local device. You can put the server application on a cloud server (hosting provider, AWS, Rackspace, etc.). Then, if you have a well-designed solution, you can access the application “in the cloud” using the client on the local device. Is this a web-based app? No. But not every business needs one.

What is my point? Let’s be honest, and not ashamed, of what FileMaker really is and is not. Be honest with yourself and your customers about whether FileMaker is the right fit. If it is, use it. If it is not, have other options to offer the customer. Do not try to fit a square peg into a round hole. It is a disservice to the FileMaker platform and the customer.

Wrapping Up

Back to FileMaker 13, the latest advancements in the platform — including the layout theme/style engine, the new layout objects (popover and slide control), the improvement in iOS functionality, and the server enhancements like Perform Script on Server — are significant steps forward. However, these do not change what FileMaker currently is: a client-server database for custom applications on desktops and iOS.

Learn how to determine whether FileMaker is a good fit for your project. Use it for its strengths and work around its weaknesses. (BTW, all development platforms have weaknesses.) If you are not sure how to do this, get help. The worst thing you can do is declare “if it cannot be done in FileMaker, it is not worth doing.”

That is my take on the state of FileMaker 13. What do you think? You can leave a comment using the form below.

Hooking Formstack into FileMaker

June 13, 2013 by Anders Monsen 10 Comments

There are generally three ways to get web-based form data into FileMaker.

You can set up Instant Web Publishing using FileMaker Server Advanced, exposing a FileMaker layout directly to the web.
You can write a custom HTML form and submit the data using FileMaker’s PHP API.
You can use a third-party interface that works with FileMaker’s PHP API.

Using IWP seems like it requires little or no effort. However, aside from the additional expense of Server Advanced, certain programming constraints still exist. Accounting for multiple layouts or conditional fields that appear based on answers can complicate your solution quickly. A custom form requires a basic knowledge of HTML and associated web technologies (CSS, Javascript, PHP, etc.), but again runs into issues if you want AJAX-like feedback and actions.

Using a third-party option like Formstack gives you the flexibility of custom HTML technologies and offloads much of the design work. Still, design is only half the picture, as you need to integrate something like Formstack into FileMaker.

Getting Started With Formstack

The starting page for any developers is Formstack’s Developer Central page. You will need a Formstack account, and there is an associated cost with this method though you can try it for free first. For our purposes we’re going to use the Webhooks method instead of the REST API. The webhooks method sends data in a key/value format to an external URL upon the form submit action. That external URL is your PHP page, where you create the code to parse the submitted data and push it into FileMaker.

Your FileMaker file is where data will end up after the form is submitted. This will need to be hosted, and set up for fmphp access. The web interface layout(s) need only the fields that will receive data from the form. This gives you a couple of options: you can use the data separation model to them hook into this database and display your data or process it for any analytics; or, you can use the same database and build your analytics process as part the solution.

Setting Up the Webhook

Once you have built your form, you open the Settings and decide where to point the form for each submission. Note the two actions in the “After the Form is Submitted” section. This is where you point to your page that processes the data, and redirect the user after the data is processed.

To process the form data, we need FileMaker’s PHP API files, Formstack’s own class (Formstack.php) and an API key from Formstack. The Formstack items are found in Formstack’s Dashboard, in the Forms tab, in the Social Media section.

You need to write at least one file, with an optional second file. The first will process the data behind the scenes. In these instances, I have simply called it “webhook.php”. I created a second page, where the form will redirect after being processed. This is a simple “Thank you” page. You can customize the Thank You to display any text you like, and include a link back to the survey.

The Webhook Code

The webhook.php files contain PHP code to handle the data.

/* FORMSTACK SECTION */
require_once('Formstack.php');
define('API_KEY' , 'YOUR_FORMSTACK_API_KEY_GOES_HERE' );

// variable to skip extract function
$skipExtract = $_GET['skipExtract'];

$formstack = new Formstack(API_KEY); //instantiate the class

$form = $formstack->form($_POST['FormID']); //internal form ID
$form_name = $form['name']; // capture name

$data = array('form_name' -> $form_name );
foreach( $form['fields'] as $field ) {
  $id = $field['id'];
  $name = $field['name'];
  $value = $_POST["$id"];

  if($skipExtract) {
   $extract = $value;
  } else {
   $extract = fs_extract($value);
  }

  // check for sub values
  if($value == $extract) {
   $data["$id"] = "$value";
  } else {
   foreach( $extract as $subkey => $subvalue) {
    $data["$subkey"] = "$subvalue";
   }
  }
}

/* FILEMAKER SECTION */
require_once('FileMaker.php');
$fm = new FileMaker('MySurveys','hostaddress','user','pwd');
$action = $fm->newAddCommand('web_layout');

// now set the fields
$action->setField('FirstField', $data['fieldid']); // see below for the number
// etc for additional fields

$result = $action->execute();

Note that in this case for the setField action you need to know the field ID issued from Formstack. To find the Field ID, you need to go to Publish >> Advanced, copy the contents of the “Form HTML” field into a text editing program, and find the field(s) being submitted. There you will see something like id=”field1234567″ name=”field12345567″ associated with each field. You need only the number. Return to your webhook.php page and fill in the fielded associated with each field you want to map for the FileMaker database. With Formstack you also can set up notifications, view stats, and more.

Job Application Form

For an example of how the front end works in action, check out our job application form. This form is created in Formstack, displayed on the web and then imports into a FileMaker database to parse the data and keep future notes.

While there might be slightly more effort in setting this up than building your own form, Formstack allows for an easy customization of forms and does most of that work for you. The required code to hook your forms into FileMaker is fairly minimal, yet the rewards save time and effort in the long run.

Dynamic Compound Finds With FileMaker and PHP

May 10, 2013 by Anders Monsen 5 Comments

The default behavior for FileMaker’s PHP API find requests is “AND.” Enter multiple criteria in the find request, and FileMaker treats this it as a “Find records where A = ‘this’ and B = ‘that’ in the request. But what happens if you need to search using OR? The PHP API documentation states that you can override the default AND behavior by setting the logical operator:

$find->setLogicalOperator( FILEMAKER_FIND_OR );

The Problem

However, each time I’ve tried this, the OR action didn’t seem to work the way I wanted. To make it more interesting, I didn’t know how many requirements would make up my OR search, as the criteria could change with each request. There might be two conditions, or six, or more. All criteria were stored in an array, and I need to loop through this array and add my criteria, but when I ran it through the loop it only remembered the last option, not each option in the array.

foreach( $itemList as $theItem ) { 
   $find->addFindCriterion( 'field', $theItem ) 
}

The documentation for FileMaker’s custom web publishing points to another option, the compound find. This takes separate find requests and stitches them together into one find. However, every example of the compound find showed static criteria, including FileMaker’s own documentation. I needed my criteria to be more fluid.

Page 35 of the documentation shows the compound find goes somewhat like this (shortened here to core elements):

// Create the Compound Find command object 
$compoundFind = $fm->newCompoundFindCommand('Form View');

// Create first find request
$findreq1 = $fm->newFindRequest('Form View');

// Create second find request
$findreq2 = $fm->newFindRequest('Form View');

// Specify search criterion for first find request
$findreq1->addFindCriterion('Quantity in Stock', '<100');

// Specify search criterion for second find request
$findreq2->addFindCriterion('Quantity in Stock', '0');
$findreq2->setOmit(true);

// Execute compound find command
$result = $compoundFind->execute();

My circumstances required that I find a set of child records, extract unique parent IDs from these, and then perform a find on the parent records based on these IDs. However, I didn’t have just two IDs, but an unknown number. In some instances the search might look at two or three records. In others it might be six, or ten.

Mission Accomplished?

First I ran an initial search to give me the parent IDs in the child table. Given a criteria in the child table I pulled up a list of all parent IDs. I looped through this to get one array with the parent IDs.

foreach ( $records as $record){
  $idList[] = $record->getfield('id_parent');
}
$idList = array_unique($idList);
$idList = array_values($idList);

I needed a unique list since there might be duplicated parent IDs in my found set, so I ran the $idList through the PHP function array_unique. I also needed to reset the keys in the array so they would go back to 0,1,2,3,etc instead of 0,3,5,33,etc. which was accomplished with the PHP function, array_values.

Once I had the final and clean list, I performed my search on the parent layout. In the FileMaker documentation example (see above) the “findreq” variable is numbered 1 and 2 (with additional requests taking numbers 3,4,5 and so on). I needed my $findreq_n to grow based on the array count. You can concatenate numbers to PHP variables, but it requires a little extra effort. What this now allowed was a more fluid and less limiting way to build compound finds. When built to match the documentation example, I ended up with two loops to construct the compound find.

// the parent array
$myList = array('id1', 'id2'); // etc

// Create the Compound Find command object
$compoundFind = $fm->newCompoundFindCommand('parent_layout');

$i = 0;
while ($i <= count($myList)):
  ${'findreq' . $i} = $fm->newFindRequest('parent_layout');
  ${'findreq' . $i}->addFindCriterion('id', $myList[$i]);
  $i++;
endwhile;

$j = 0;
while ($j <= count($myList)):
  $compoundFind->add($j,${'findreq' . $j});
  $j++;
endwhile;

// Execute compound find command
$result = $compoundFind->execute();

The use of such “variable variables” is sometimes discouraged, given potential problems. However, in this case the variables worked, whereas previous attempts to get the logical operator OR to work either within a for each loop or without any loop failed.

While this also allows for unlimited OR criteria, for performance issues this isn’t always a good idea. However, if you know the count of the parent array, you can always limit the action based on the count. One choice might be to check if it exceeds a certain number and then re-think the search options.

Let’s Optimize!

The above while loops seems acceptable, but redundant. Furthermore, what if we want multiple criteria in the find? It seems that a cleaner solution is offered by the foreach loop.

$i = 0;
foreach($myList as $myItem ){
  ${'findreq' . $i} = $fm->newFindRequest('parent_layout');

  // add the criteria to the request
  ${'findreq' . $i}->addFindCriterion('Location', 'Some Condition'); // second criteria
  ${'findreq' . $i}->addFindCriterion('id', $myItem); //original ID

  // Add find requests to compound find command	
  $compoundFind->add($i,${'findreq' . $i});
  $i++;
}

This method removes the need for two while loops that separate the addFindCriterion() and add() methods, reads much better and ends up with cleaner code.

Conclusion

Using compound finds provides an alternative to the set logical operator method, and even though there are more lines of code, it appears to work fairly quickly. Hopefully, if you ever have run into the need for compound finds, you might this dynamic method useful, especially as a result of form-submitted data.

6 Text Editors for PHP Development – Part 3

July 6, 2011 by Anders Monsen Leave a Comment

This is the third in a 3-part series.

To conclude this series, we continue with the best paid Mac apps available. (See Part 1 and Part 2.)

BBEdit 9.6

I’m slightly prejudiced here as I’ve been using BBEdit for pure text editing since the mid 90’s. Habit breeds comfort. The big brother of TextWrangler, BBEdit costs $99.99, and has been around a long time. In areas it clearly shows its age, especially in the UI. It can be somewhat intimidating for the new user, and debugging errors can take time, indicating the need for better debugging tools, a topic for another time.

BBEdit has a vast array of keyboard shortcuts, and you can add your own. You also can create text clippings that can be invoked by typing the first characters of the file name in which you saved the clipping, which saves considerable time. Code intelligence speeds up development, but some of the word suggestions can be annoying (though this can be turned off). Balanced braces are not added automatically, but you do get hints when they are balanced, and you can select them to make sure they do balance.

Sometimes when writing a function in FileMaker with nested brackets, I’ll bring the function into BBEdit to verify the “(” are all balanced with a matching “)” – a feature I wish FileMaker had in the calculation dialog. BBEdit lets you either open documents in a drawer – no tabs – or independently. The latter is nice when you want to stack documents to compare them side by side. You can do this manually or have BBEdit show differences between the frontmost two documents. Although compared to new apps and IDEs, BBEdit seems somewhat old school, it remains my go-to tool for clean editing with lots of power, but minimal frills.

Coda 1.7

Costing $99 (about the same as BBEdit), Coda looks and feels far sleeker than the venerable Bare Bones product. Created by the same people who make Transmit, Coda bills itself as an all-in-one development environment, with text editing, project management through what it calls “sites,” CSS design, Terminal access via SSH or local shell, and reference books. Coda’s UI is seemless. The Clips palette floats on the screen. You can split the main editing window multiple times, not just once like in BBEdit, and you can split vertically or horizontally.

The code completion comes with the reflexes of a cheetah. Adding new styles to CSS documents is a breeze. You can work locally or remotely, or work locally and publish to a remote host through the Sites. I wish it would default to open the site files in the navigation panel, and not just the last stored open tabs, but this is quickly fixed in the preferences.

Conclusion

I believe that the app you choose will generally reflect your personality. People with PHP experience who already have their favorite app won’t be swayed by any opinions above. After going through each of these six apps side by side I found some that complement each other, and some that make me consider my current choices. I’ve listed the version numbers next to each app, as things change over time as new versions are released.

Some other editors worth mentioning include SubEthaEdit, a great collaborative tool; the Java based jEdit ; Smultron, formerly free and now available at the Mac App Store for $4.99; Gnu Emacs a cross-platform tool based on Lisp; Bluefish Editor, with both native and Macports flavors.

TextWrangler is the minimum app one should have for any text editing. KomodoEdit, for the amazing cost of $0, is the next choice for day-to-day work. Coda’s UI is modern and self-contained, and for a relatively new app it is hard to resist. BBEdit works well for heavy lifting – searching multiple documents, comparing data, but shows its age. I’ve used it so long, I always held the belief that you could take it away when you pry it from my cold, dead fingers. I know people who feel the same way about EMACs and other text editing apps.

Whatever your ultimate choice, writing PHP code can be frustrating, time-consuming, and yet ultimately rewarding as you see patterns and discover shortcuts. Taking the time to become familiar with one or two text editors ultimately will save you hours of effort over time. Creating code snippets and storing these for further use via BBEdit, for example, almost makes me blush every time I call them with five or fewer keystrokes.

To learn more about building web pages to display FileMaker data using PHP, check out my PreCon session at FileMaker DevCon, Core Elements of PHP for FileMaker, Tuesday, August 2nd at 1:30pm.

6 Text Editors for PHP Development – Part 2

June 29, 2011 by Anders Monsen 6 Comments

This is the second in a 3-part series.

In my previous post, I covered a couple of free applications. In this installment, I look at two paid text editors, both with strong caveats.

UltraEdit 2.1

UltraEdit presents another clean, cross-platform option, albeit one that is not free. When I opened the app the first time, it hijacked all .php and .css files and made itself the default application. I prefer a choice in the matter, and although it took seconds to switch back, this was annoying. UltraEdit comes with a 30-day trial, and costs $59.95 for a full license.

You can open multiple files in a tabbed view. Line numbers are on by default, and color-coding manages PHP and HTML side by side. Find and Replace actions are separated via tabs in the Find and Replace window. You can create project workspaces or work with independent documents. If you have the screen real-estate you can display a variety of views, from files to function lists. This tool might be one to grow with and make the transition to an IDE easier. It also has a Windows feel to it, so if you’re making a transition to the Mac from Windows there might be a comfort factor here. I don’t know if UltraEdit stands out enough from the other apps to make me adopt it as a daily tool, but it’s still a strong app to consider.

TextMate 1.5

TextMate‘s strength appears to lie in managing projects, or possibly other development languages like Ruby on Rails, not so much PHP. One very nice feature is that the project window lets you drag and drop a folder into the drawer, and you instantly have access to all the files. Each file you select opens in its own tab.

There are pros and cons with tabbed text editor views. The main advantage is real-estate, as you keep all windows within the application. The disadvantage comes when you want to compare documents side by side. Inside each document the color-coding shows up nicely, along with shaded areas where you can fold the code between matching tags. Line numbers were not apparent in the document, only the footer line. Also, the preferences in TextMate are sparse.

The biggest downside for the new PHP developer is dealing with code completion. In TextMate this requires that you start typing and then press the ESC key. The function still does not fill in the parameters. For example, in_array just codes as red text and contains nothing after the term. Possibly there are ways to enhance this through some additional programming. After seeing other FileMaker developers advocate for this tool, I’ve tried several times to get comfortable using with no success.

You can download a 30-day trial version. The cost for TextMate is $57. I expected something more for the price so I can’t recommend this for PHP development.

In comparing these two paid apps to the free ones in my previous post (TextWrangler and KomodoEdit), both in my opinion fall somewhat short. As I see it, these types of apps should be relatively intuitive, but both UltraEdit and TextMate made me spend time cleaning up, or finding features and ways to use them. In the next post I cover two additional paid apps, both with fewer limitations than these.

6 Text Editors for PHP Development – Part 1

June 27, 2011 by Anders Monsen Leave a Comment

This is the first in a 3-part series.

Anyone new to PHP development with FileMaker will need a text editor application to write the PHP, HTML, CSS, and other code outside FileMaker. In this series of three posts, I’ll review some of the better-known text editors for the Mac OS. I researched this information to prepare for my PreCon session at FileMaker DevCon, Core Elements of PHP for FileMaker, Tuesday, August 2nd at 1:30pm.

I’m not necessarily talking about “best practices”. For full-time PHP development, you would typically use an integrated development environment (IDE) with revision control and project management for local and remote files. However, an IDE is a major investment in learning (and in some instances money), and the leap to a fully-fledged IDE rarely happens all at once.

Most users start off with an advanced text editor that still has rich features to help with development. I’m not going to cover all available applications, only ones which I have used over the years. The six apps that I will review are sufficiently different, and users will develop their own preferences; in some cases it may be useful to have more than one available. As I do most of my development in the Mac OS, all the tools I mention are Mac-oriented, though two of them are cross-platform.

Although every Mac comes with TextEdit, it is far from ideal for reasons because it lacks “code awareness.” For example, it does not have color-coding, so you can see the code on the screen at a glance (PHP vs. HTML), or element recognition, the type of elements in each language (function vs. string). Also, TextEdit tends to save documents in Rich Text Format (RTF).

Still, free is good, and two of the six apps I cover are free. These free apps have virtually all the features that you need, and one in particular is worth as much as some of the paid apps.

TextWrangler 3.5

One of the first things I do when setting up a Mac web server is to install TextWrangler. Made by Bare Bones Software, who also make BBEdit, this application is perfect for development at zero cost. It comes with many of the features as its big brother, such as multi-file search, document comparison, color coding, and a vast array of keyboard shortcuts. There is no code complete or clippings (although you can store documents in a Text Factory folder). I would hesitate to use TextWrangler for large projects, but it’s perfect for quick work.

KomodoEdit 6.1

A quantum leap from TextWrangler is the cross-platform app KomodoEdit. I first heard about it from MightyData’s own Visionary of Value, Kirk Bowman, while reading through the DevCon materials from his session on PHP and FileMaker in 2009. Free and cross-platform? What’s not to like? I’ve promoted this app in my own classes on PHP and FileMaker because of the instant value.

Clearly, the people who developed this software see it as a gateway to their full-fledged IDE, and they advertise this option in the Start Page when you launch the app. The default extension is a text file, but a simple change in the preferences and your new documents are created with .php extension instead.

KomodoEdit is like a mini-IDE, handles project management quite nicely, and even debugs code within the document (to some degree). If you make a common beginner mistake such as leaving off a semi-colon, the area around this gets a red underline to alert you that something is wrong. You can split the text window (like Excel), code folding is intuitive and visual, and the preferences allow a great deal of fine-tuning.

KomodoEdit is hands down the best free text editor for the Mac, and even better than several paid apps. I have on occasion run into strange issues with inconsistent color-coding. Also the soft-wrap option adds a distracting character on the right side of the screen when text wraps. But these are minor issues. And did I mention that it’s free?

A Simple Debug Function for PHP

May 23, 2011 by Anders Monsen 8 Comments

As FileMaker developers, we rely heavily on FileMaker Pro Advanced, which lets us step through scripts and test variables on the fly. Unlike in FileMaker, there is no Data Viewer and Script Debugger to make life easy in PHP development. We can take a manual approach or just as with FileMaker solutions write a custom function to do all the heavy lifting.

The Old Way

When trying to decide the content of variables that fail, developers usually print these to the web browser, using either “echo” for strings or “print_r” for arrays.

We quickly discover that large arrays look messy with just print_r, and so the next step is to wrap some “pre” lines around this to format the array into more readable text.

echo '<pre>';
print_r( $array_name );
echo '</pre>';

Even these three lines can get end up crowding your page as you are writing code. When stepping through the various arrays returned by the PHP API for FileMaker using a newFindCommand, adding these three lines in between each variable, and then commenting these out while debugging, can become tedious. The simple query below has five possible places you might want to check the content of the variable.

$find = $fm->newFindCommand($layout);
$find->addFindCriterion('field', $value);
$result = $find->execute();
if(FileMaker::isError($result)) {
 $error = $result->getMessage();
 die($error);
}
$records = $result->getRecords();
$record = $records[0];

A Better Way

Writing a function for PHP is somewhat similar to the method in FileMaker. The function requires a name, parameters, and calculations to serve the purpose of the function. You can store your functions in a separate functions.php page that you include in your PHP page, and call the function as needed. The function that I created to check what happens to each variable takes an optional parameter in the end to decide whether to output to the browser. So, I can include this function as one line in multiple places without worrying about commenting out the code.

function display_debug($key, $value, $debug=false) {
  if($debug){
    echo ''.$key . " = ";
    switch (gettype($value)) {
      case 'string' :
        echo $value;
        break;
      case 'array' :
      case 'object' :
      default :
        echo '';
        print_r($value);
        echo ''; 
        break;
} } }

There’s nothing too fancy here. I have in fact borrowed the main part of a function that comes with the PHP Site Assistant installed by FileMaker Server. It checks whether the variable is a string or array. I modified the function to include the key or variable name in bold, and also added the “pre” around the print_r to format the array.

Using the Debug Function

When I need to call this function, I simply call one line. The default has only two parameters.

display_debug('$findall',$findall);

Without the optional third parameter, nothing appears on the page. Add a “1” and this function becomes live.

display_debug('$findall',$findall, 1);

The variable inside quotes will let this appear as text, letting you search if multiple variables appear on the page. Often you need stop points after certain sections of code, in which adding the command “die();” would let you focus on just that section.

Debugging code is part and parcel of any development effort. Even when everything seems to work great, to echo the arrays or strings stored in variables validates your code and acts as a sanity check. Testing for errors or determining the cause of errors require stepping through all possible locations this may happen. With a function handling displaying the variable contents and not using print_r() on each page, your code ends up cleaner on each page and cleaner overall.

PHP Development for FileMaker Developers

April 29, 2011 by Anders Monsen Leave a Comment

PHP is a fairly flexible language, where developers can create sites using linear or procedural code, or complex object-oriented code. The fact that you need to type most of your code and understand a new syntax is daunting to anyone, especially FileMaker developers who are used to the built-in GUI, native script steps, and pre-existing functions. The ease of setting up a database in FileMaker is one of the primary draws of this software. Despite the more manual effort required when writing PHP, there are many analogies FileMaker developers can use to become more comfortable with the code and process of PHP.

FileMaker solutions generally contain three elements: the data, the logic, and the user interface. In web-based solutions PHP acts as the logic layer. The data exists elsewhere, either in MySQL tables, FileMaker databases, or some other external database. The user interface relies on HTML, CSS, Javascript, Flash, and other interface tools. By finding common ground between certain FileMaker features and PHP scripts we can ease the transition from one to the other.

The core of FileMaker’s logic layer is scripting and calculations. FileMaker scripts are comprised of built-in script steps with various options or parameters. FileMaker calculations combine elements such as text strings, numbers, fields, operators, and built-in functions. Developers can write custom functions, and external plug-ins create more functions. PHP pages often appear side by side with HTML, but strip down the code to just PHP and the appearance is much like a FileMaker script — a sequence of statements, such as variables, function calls, conditional branching, loops, etc.

Although there is no list of script steps to select from in PHP, PHP statements are made up of a series of steps, just like in FileMaker. Just as new FileMaker developers stumble when trying to select appropriate script steps to build specific scripts, PHP developers need to familiarize themselves with certain key functions. For example, a foreach loop in PHP could be expressed in this way:

foreach (array as $item) {  <##> }

Here the array, $item, and <##> are parameters where the developer must consider content and format, much like Set Field [table::field ; value ] contains two different parameters.

Another approach would be to separate PHP functions into two groups: those that look like scripts and those that look like calculations. In the latter group you have built-in PHP functions like substr, number_format, in_array, etc. These tend to appear as short, single-line calculations with one or more parameters. A few years ago Jonathan Stark created a reference page to map such calculations. Here we can see many parallels between FileMaker and PHP, such as Left( “FileMaker Pro Advanced” ; 4 ), which is expressed as substr( “FileMaker Pro Advanced”, 4 ) in PHP.

Another useful analogy takes place in the use of variables. FileMaker variables take the form of local (single $ followed by a text string), and global (double $$ followed by a text string) variables. Most PHP variables start with the single $ followed by a text string. Although $$ variables exist, these are called “variable variables” in PHP, and behave completely differently from FileMaker’s global variable, such that novice developers should not use these.

Just like the Set Variable [$varName ; Value:”varValue” ] script step in FileMaker, PHP takes a similar format, without the “Set Variable” declaration. Instead, the variable is declared and set with the single equal sign.

$phpVariable = substr( "FileMaker Pro Advanced", 4 );

This sets the value of $phpVariable to “File.”

Understanding variables implies their use within functions. If you declared a variable to “FileMaker Pro Advanced,” you could then use this variable in the function.$versionName = “FileMaker Pro Advanced”;$phpVariable = substr($versionName, 4 );The next logical step is to make the contents of $versionName dynamic, either as the result of a form submit action, or a query. Novice PHP developers run into issues when comparing data, as something like if( $myVar = “this”) actually sets the variable, while the double equal sign is the correct method: if( $myVar == “this”).

The essence of integrating FileMaker and PHP is expressed in four requirements: Creating records, Reading or retrieving records, Updating records, and Deleting records (or CRUD, for short). Total integration does not stop with these four elements. Getting layout information and value lists can make interfaces more dynamic. There are functions to execute FileMaker scripts and gather portal information, as well as critical error-trapping methods. However, CRUD is the building block upon which everything else stands.

One of the earliest and most concise write-ups on FileMaker’s PHP API came from Six Fried Rice on PHP API and FMP 9 from May 2007. All the points made here remain valid. Jonathan Stark and Chris Hansen’s comparative essay on FX.php and PHP API – is an excellent overview of the two PHP classes.

Some integration examples of FileMaker and PHP include Joomla, a content management system (CMS), detailed by the folks from myFMButler on integrating FileMaker and Joomla. Another popular PHP framework is CodeIgniter. With minor modifications it is possible to integrate this framework with FileMaker using FX.php.

Further, Google maps, which combine PHP and Javascript, can be integrated into FileMaker through the Web Viewer. A PHP page resides on a server. FileMaker interacts with this page, sending data from each record into the PHP script, which then interacts with Google through their API, and displays the result in a Web Viewer on the FileMaker layout.

Recently Matthew Leering’s post on Google Analytics and FileMaker showed how you can gather data from arrays and insert these into FileMaker. There are several web services that offer APIs to place arrays of data into PHP variables through queries, which developers then can turn around and insert into FileMaker records and fields.

Integration between FileMaker and PHP works both ways, making FileMaker one of these most flexible and powerful database solutions available to individual and enterprise users. From creating custom web front ends to your FileMaker database, integrating with existing CMS frameworks, and writing scripts that import data from web sources into your solutions, the marriage of PHP and FileMaker has tremendous potential. The above examples show just a few of these opportunities.

Web Publishing

Client-Server

Wrapping Up

Getting Started With Formstack

Setting Up the Webhook

The Webhook Code

Job Application Form

The Problem

Mission Accomplished?

Let’s Optimize!

Conclusion

BBEdit 9.6

Coda 1.7

Conclusion

UltraEdit 2.1

TextMate 1.5

TextWrangler 3.5

KomodoEdit 6.1

The Old Way

A Better Way

Using the Debug Function

Let’s get started on your project.