Greetings,

I'm trying to develop my PHP files in such a way that they can be easily understood by other PHP developers, not necessarily Filemaker developers.

Being new to PHP, I started reading various tutorials about how people write PHP, specifically around database connectivity. Much of that information had to do with mysql as the backend. The common thread in the file organization I observed was a modular approach, such that variables defining the host database were defined in a 'config.php' file, the instructions to connect or disconnect were in 'conn.php' and 'disconn.php' files which included the config.php file, and finally, the files that did the heavy lifting just included/referenced conn.php and disconn.php as needed.

I'm trying to apply that to my Filemaker work, but it doesn't seem to be going so well. I can declare variables in a config.php file, setting $$dbhost to 'localhost', $$dbport to '80', etc. But when I instantiate fm-and-php, that seems to be the end of the road. Whatever I'm going to do with that instance of fm-and-php, I have to do it in that file.

I had hoped to have the variables defined, a file to instantiate fm-and-php, then a series of files to send commands to it: view, find, findall, new, etc...

Seeing that I'm having trouble splitting up the code like this, I wonder if I'm just doing this the hard way.

Thus, at long last, the question: how do you PHP/FileMaker folks organize your sites? Are there any templates or guidelines I should follow? Does it make sense to split the functionality of my PHP code along the lines I outlined above, and if so, how do I do it?

Any pointers appreciated.

Although I'm using fx.php rather than fm-and-php, here's how I've organized my files:

Each page begins with the following line:

require_once('functions.php');

functions.php begins like this:

require_once('FX/FX.php');

require_once('FX/FMErrors.php');

require_once('constants.php');

ini_set('include_path', 'includes/' . PATH_SEPARATOR . ini_get('include_path'));

require_once('HTML/QuickForm.php');

import_request_variables('pg', '');

If you're not using the HTML_QuickForm PEAR module, you can eliminate the fourth and fifth lines.



The rest of functions.php includes functions that my system needs. For instance, here's my function for NewFX()

function NewFX($layout)

{

  $fxphp = new FX(SERVER_IP, WEB_COMPANION_PORT);

  $fxphp->SetDBData(LAUREL_FILE, $layout);

  $fxphp->SetDBPassword(WEB_PW, WEB_UN);

  

  return $fxphp;

}

My coding convention is to use caps lock for constants. Those constants are defined in constants.php. With the above function, whenever I want a new instance of fx.php, I use something like:

$acctFX = NewFX('WebAccounts');

Having said all of that, I plan to break functions.php into multiple files: functions_fx.php and functions_quickform.php.

This is just a guess, but the problem may be that you are trying to alter an instance within a function without passing the instance as a reference, and therefore the function can't actually alter the instance, but only a copy of it. As an example, here's a function I have that will take a QuickForm object and a heading prefix and edit the actual object (because it's being passed by reference with the & operator in the parameters list):

function BeginReqAddlInfo(&$form, $headingPrefix)

{

  global $AVAIL_ADDL_INFO;

  $heading = $headingPrefix . 'Heading';

  $form->addElement('static');

  $form->addElement('static', $heading, NULL, $AVAIL_ADDL_INFO[$headingPrefix]);

  $renderer = &$form->defaultRenderer();

  $renderer->setElementTemplate(STATIC_TEMPLATE_BOLD, $heading);

}

Chuck