FMP Best Practices : Script configuration variables

[John A]

Hi all,

  Looking for advice on best practices (or maybe just what you are doing..) in regards to setting global configuration data for all scripts running within a file.

 

Our situation specifically is FMP11 Server with FMP11 -and- PHP clients.

 

We have need of global configuration variables. These are things like 'are we in test mode' or 'authorize.net api key'. Things that all scripts need access to but are global across sessions.

 

We have approached this in 3 ways with different problems

 

1) A configuration table with key/value pairs.

Pro: Essentially makes each config element a singleton value. Easy to manage

Cons: Selecting records out of it is a bit of a pain in FMP scripting (easy in php though)

 

2) A table with all globals as fields set to global, initialized at file opening by a startup script so everyone gets the same values

Pro: Works great in FMP client!

Cons: PHP never retrieves these values (bug? not sure, no one seems to know)

 

3) Instead of setting fields in (2) to global we set them to calculations that always return the specified data. This is PHP compatible ghetto globals IMHO.

 

My question for the community is: How are you managing global configuration data?

 

Version 3 seems simplest for me but just feels.. wrong.

 

Tx!

John-

[doughemi]

I think the best way is a one-record Globals table, with a field for each value you want to set.  The fields should not be global fields, just normal fields of whatever type you need.  In a hosted file, global fields are unique to each user (which is why your PHP scripts can't access the correct data.  The only way to have data in global fields universal to all users in a hosted file is to set the values when the file is directly opened by FileMaker Pro).

 

To access the data in the Globals table, you would create as many TOs as required, and relate each of them with a Cartesian relationship (the X operator) to a TO that needs to access the data.  For your PHP scripts, simply create a layout with every field that is in the Globals table.  For example, if you have a Contacts TO, you would have a relationship  Globals~Contacts::SomeField X Contacts::SomeField.  Note that with an X relationship, every record matches every record, so the field defined in the relationship is immaterial.

[John A]

Thanks Doug, thats a great solution and clearly explained. It lets me not do 'yet another lookup' and seems pretty clean!