FileMaker and PHP: Link to A Record Using Redirect

/6 Comments/in , , /by

Let’s Learn How We Can Link to A Record Using Redirect

In this article we’ll look at how you can link to a record using redirect with FileMaker and PHP.

In later versions of FileMaker we have Snapshot Links. When you work in a database you can always give someone a Project number when you need to refer to a Project. Or we can script generating a Snapshot Link. The problem with the Snapshot link is that you’ll have to remove it once you spit it out to the Desktop. AppleScript can help with that.

Another method is the fmpURL protocol. You can generate nice links such as this:

fmp://localhost.com/SomeDB.fmp12?script=open_project_link&param=PROJECTID

Then if you copy and paste this into apps it’ll open the database. If you’re on a Mac and use Messages or email this is great!

But then I ran into a problem where my client’s law firm relies on Gmail for their primary communication AND they are using it from a web browser. Now, Gmail DOT NOT know what to do with the FMP protocol so it just breaks the URL and funky things happen. I’m sure Gmail is not the only party here that does not know what to do with it.

So one—fairly simple method—of tackling the problem is referring to good old, creating a link to a record in FileMaker with PHP. I know, this is not a novel method but when I was looking for it I couldn’t find a comprehensive article on how to achieve what I want.

What you need:

  1. A web server
  2. A PHP file
  3. A script in FM that will know what to do with the parameter it receives
  4. A button on the layout to run another script to generate the appropriate link to call your redirect PHP

Any web server anywhere will do. You just need to place a very simple redirect PHP file on it. Name it “redirect.php and place it in the appropriate document folder of the web server. Make sure the file has the proper (read, execute) permissions.

The PHP file:

<?php

//gets the query string for the value of ‘project’
$project=$_GET[‘project’];
//concats url with ID from query string.
$url = “fmp://YOUR_FM_SERVER/Database.fmp12?script=SOME_SCRIPT&param=” . $project;
//redirects to new page.
header(“Location: ” . $url);
?>

The FileMaker Scripts

  1.  You need a simple script that the PHP file will call. It will need to define the received parameter and perhaps search for the aforementioned project by ID. Obviously the script can do more, depending on your business process.
  2. And the script that calls your redirect.php on the webserver. It should generate and copy your link to the clipboard:

    https://YOUR_WEB_SERVER/redirect.php?project=PROJECTID

Then that link can be pasted anywhere and will be clickable.

Getting Data From WordPress To FileMaker II

/1 Comment/in , , , /by

In my previous post, Getting Data from a WordPress to FileMaker I detailed how you can get mySQL data (that perhaps comes from a WordPress form submission) into FileMaker.



This time I’ll write about how you get that data into your own FileMaker table.



I recommend “importing” the data from the mySQL database into a temporary table. We called ours APPLICANTI_TEMP.  It contains the same exact fields as the mySQL database and it is there so you can identify records in between the two tables. So in my case the fields are text fields, just like in the mySQL DB (even the timestamp). But then we added a timestamp field that is a regular FileMaker TimeStamp and when we run the scripts we set this with the proper FM TimeStamp.


I added two calculations:

  1. One that checks whether the record we are viewing exists in the mySQL table and
  2. Another one that checks whether we have added the record to our APPLICANT table.



Screen Shot 2015-04-15 at 6.45.02 PM



These calculations are quite limited but in my case achieve the wanted result. I am not too worried about someone modifying the records in the mySQL table, because I’m the only one with access to it. But you’ll have to make decisions based on what’s best for you. I, however wanted to make sure I’m not creating the same record several times in the APPLICANT table. Well, we still are, because people apparently fill out and submit the form (sometimes with mismatched information?!?) several times. So at the end of the day you’ll still need a human to identify if a second record has a misspelled last name or it is, indeed a different applicant. But in case you have a scenario that disallows record deletion based on some criteria, you’ll need to develop a more refined logic.



I have already converted my SQL TimeStamp to a FileMaker readable timestamp, but if you don’t do that in your Query you’ll have to do that in FileMaker. Bring Dunning’s Custom Functions collections is always a good place to start looking for handy custom functions.



Screen Shot 2015-04-15 at 7.07.08 PM


We have a set of scripts that perform the data move (because it’s not really an import). They loop through a set of fields on a layout record by record and create the record in the TEMP table, then the APPLICANT table. These scripts are run from the server every 15 minutes. You set your time interval based on your own process.


The first step is to refresh the data from the mySQL database, because unless you do that any new submissions from the web (in my case) will now show in FileMaker:



Screen Shot 2015-04-15 at 7.10.51 PM



Before running scripts from the server, always make sure you test the hell out of them locally first. Here’s an article on server-side scripts in general. I always recommend adding a LOG table, and put in error checking in your scripts, especially when you’re running them from the server. You DO NOT have a debugger on server. And who wants to code blindly?!



And if you’re lucky—like us—you’ll have to parse the data into different tables, because you’re dealing with parents, addresses and phone numbers. You’d obviously want to do that from the TEMP table record.

Hope this covers it all. Any questions, feel free to ask.

Coding Principles And How They Apply In FileMaker

/1 Comment/in , , , , /by

Coding Principles in general

When I dabbled in development first time I had no idea I actually was developing. I was just adding a few fields here and there. Mostly I just wanted a way to record information on tracking film materials, dubbing, etc. And for the next decade I did the same: I hacked my way to getting things done for the boss. And while I tried to protest, the boss always won and said “but I need it now.” That leaves zero time for planning or building architecture. So I was more of a firefighter than developer. The next decade I spent learning development from scratch and I keep learning.

Simplicity is the most important consideration in a design

Whether you’re a hard core coder who eats, sleeps and breathes code or a school teacher turned FileMaker developer, you sure have some principles that you abide by (and if you don’t you should). We live by principles, so why shouldn’t we code by principles? And when you code, you often ask yourself “is this the best possible way to solve the problem?” In FileMaker there are at least three ways to do the same things. And there’s a different

Since this blog is mostly dedicated to FileMaker development (at this point), I’ll just take a stab at some coding principles and see how they apply to us, FileMaker developers.

YAGNI (You Ain’t Gonna Need It)

The idea is that you should code with the goal in mind to program for what you need not what you might need. XP co-founder Ron Jeffries has written:

“Always implement things when you actually need them, never when you just foresee that you need them.”

The temptation—to create something—is large for a developer. It is like putting a knife in a surgeon’s hand or giving a pencil to the architect; they will want to do what they do best. We want to add bells and whistles and we want to blow the client away. But just like furniture shopping at IKEA, we can end up with a lot more than we can take home. It’s better to code for what the client needs than what the client wants. Personally, I’m an advocate for this and I always tell my clients: “I will give you what you need but not what you want.”

Worse Is Better

Aptly, also called also called “New Jersey style”.  [And if anyone ever wants to mock Jersey, again, they will meet my fist.] The idea behind it is that “quality does not necessarily increase with functionality”.  So what this does is it uses a scale to measure which one is heavier and says simple is heavier than correct. So to me this boils down to getting a solution off the ground and into the users’s hand rather than making it perfect.  You need to cover as many aspects as you can to make it practical. Your design needs to be consistent but simple. So, buttons, element placement and font sizing should be consistent from layout to layout. Luckily we have FileMaker 13 now so if you use a built-in template (or build your own)it’s hard to go wrong.

KISS (Keep It Simple Stupid) principle

This acronym is a design principle noted by the U.S. Navy. Achieving simplicity should be the goal at all times, and avoid unnecessary complexity. Design your layouts with fewer buttons and make sure they do the most important functions. Then you can take the user to a different tab or layout to give them further info. Give them a drop-down menu with further options if you must.

Don’t repeat yourself (DRY)

When FileMaker gave us variables, it became possible to start writing universal scripts. If you’re still not using variables you’re missing out on something great! They allow you to compact your code. You can write one script to create, delete, modify a record and give parameters to tell what layout you are coming from, what your table is, where you need to end up when you’re done. Of course, there will be variations which you can put in an if statement if you need it. But if you can create something once and reuse it, you’re golden. Below is a script we use to strip fields (after a user adds data that) from unnecessary garbage.



clean-field-script

Clean Field Universal Script



 

 

 

 

 

 

More useful coding principles: Wikipedia