Filemaker php interface vs converting the database to MySQL:
My client has a Filemaker database that contains over 15000 records that he set up. He has spent some time trying to build a php interface. He would like me to use the Filemaker php interface to build a website. I've been doing websites for a few years now, I know HTML,CSS, PHP and I could convert the whole thing to MySQL. But then I'd have to do the data conversion and wondering if I'm making more work for myself.
I don't know much about Filemaker and I'm wondering what the overall opinion of Filemaker is? Has anyone
tried doing this and how easy is it to use PHP to get FileMaker data? Is it equivalent just making function calls in MySQL? Or should we just convert the whole system to MySQL?
Any feedback would be appreciated. Thanks.
Last edited by ireneatpwd; 10-13-2012 at 11:26 AM.
I'm not familiar with FileMaker, but it looks like there may be some good resources at http://www.filemaker.com/search/inde...a=Search%23911.
PHP is the official language for integrating FileMaker Pro databases with the web. PHP is installed along with FileMaker Server (unless you choose to use your own installation), and the FileMaker API for PHP is a OO PHP library of functions for interacting with data stored in FileMaker Pro databases. You can more about using FileMaker and PHP here...
There's also a 3rd party library called FX.php which has been around a long time...
I'm not sure whether it's been kept current with the latest FMP releases, but you can check the GitHub repository for details.
You'll probably also want to also join the free FileMaker Technical Network developer community so that you can ask questions and get advice in the Using Web Technologies discussion forum...
Hope that helps clarify FileMaker's relationship to PHP - it's a strong one.
There are a number of options for using PHP with FileMaker. The new custom web publishing feature within FileMaker Server 12 Advanced is substantially faster than the previous versions. So that is probably the first option a person might consider.
Of course, another option is to convert the FileMaker database data, structure, business logic and layouts into a PHP web application running on MySQL. This type of conversion is often done in order to provide improved performance and scalability since there are limitations of 100/200 simultaneous users for either IWP or custom web publishing using PHP.
Most people don't realize it, but there is a wealth of FileMaker metadata available in XML format for performing these types of conversions. This XML info is available either thru copying the layout via the clipboard or reading it from the Database Design Report XML file. I have found the clipboard data to be the most reliable source of this info.
There are tools available to parse in the XML and analyze the database.
It is even possible to automate the PHP conversion using this technique (perform a Google search for "FileMaker to PHP Conversion" for more info).
Each object on a layout is represented in XML, along with style and position info. This info can be used to create form files representing the same look as the original layout. In fact, it can be difficult to see the difference between the web application and the original database if you get all of the object properties implemented. And this is what my customers request, because they don't want to have to retrain their employees. They want the web application to look and work the same as the original desktop application.
I have done a few of these conversions recently into the CakePHP framework. Here a few techniques I used:
Auto-Enter Calculation Fields - Stored calculation fields are calculated and stored within the model saves a record to the database.
Unstored Calculation Fields - Unstored Calculation fields are calculated in real-time within the form controller - but only for fields actually displayed on the form. This prevents unnecessarily calculating these values if they aren't being used on a form, improving performance.
Global Fields - A Global field in FileMaker is used like a global variable in programming languages. It is important to know that each FileMaker user gets there own private copy of global field data. There is no equivalent feature MySQL or other SQL database servers, but this functionality can easily be simulated using SESSION variables. Therefore each web user will still get their own private SESSION data, simulating the same functionality originally present in the FileMaker database. I structure these globals in the model data array as if they were retrieved from the model, meaning that converted scripts and fields on forms can reference them easily. Just before the record gets written into the database, the results are saved into SESSION variables for persistence.
Vector Graphic Objects - FileMaker layouts frequently include rectangles, ovals and line objects. These objects can be replaced with the RafaelJS library, providing high quality resolution independent graphics.
Value Lists - Custom and Field based value lists are implemented in a centralized location within the AppController.php file. Therefore making a change to the definition of the value list within the AppController, succeeds in changing the menu automatically throughout the whole application.
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)