Where to store the PHP?
I was just curious as to how everyone is storing their smartpill php scripts. I have been using the setfield script step, setting a smartpill_return field to the result and then using a calculation such as:
Let (
_code = "php code here" ;
PHP_Execute ( _code )
)
I figured in the beginning this would produce the least amount of overhead but am finding it to be quite a chore to work with. My biggest issue is having to comment out all the quotes in the _code plus adding carriage returns to each line so it executes properly. This makes the code quite difficult to read and thus hard to troubleshoot.
So is there something I am missing? There must be a better way. I have contemplated using global fields, but then I think I don't want a bunch of global fields bloating the solution. I have also contemplated creating a file like the test file that has two fields, on field with a name and the other with the php. I could then create another field in the solution that would be used for the relation.
Then I could have something like :
Set _relatedField (phpFile::script1)
Set _responseField ( PHP_Execute (filename::_relatedField))
Anyone have any ideas as to what would be the best way to do this?
Thank You
Bob
Storing Code
I am back on the FileMaker Program - I havn't been working with FileMaker since version 4 - so almost full php support in FileMaker simply blows me away - thank you for this plug-in guys.
I am using my own namespace to store all my php class files like you whould do with at java namespace. I simply put my namespace folders in: /Applications/FileMaker Pro 9 Advanced/Extensions/PHP Support/includes/
By the way I had to add the folder PHP Support with the includes folder inside.
Remember to create your unique namespace - because if you like to use some cool php lib you have to avoid naming conflicts. Being developing hardcore ActionScript OOP solutions for years - I am using the Flash / Flex communitys way of creating namespaces - simply reverse url if I lived in US my namespace whould be com/tr/ or neather lands it would be nl/tr/.
I simply make the folder dk and inside that the tr folder.
I am only starting to test things - But i think custom functions to store some of the code but mostly like wrappers that simply uses require_once so I invoke functions/methods from extenal files.
Here is an example - you can try it in the test bed you downloaded from this website.
$nameSpace = 'dk/tr/';
echo "\n\n" . $nameSpace;
require_once($nameSpace . "testExternal.php");
echo "\n\n" . testFunc('Hi my name is Thomas I like to use my favorite editor');
//Include MYSQL Class
require_once($nameSpace . 'connect/mysqlConnectClass.php');
require_once($nameSpace . 'settings/constands.php');
Is there anybody who have tried this with the server I would like to hear if it works.
How about creating a plug-in for ActionScript mtasc support / flex support.
I hope that this is an idea others can benefit from I really think it is the way to go I haven't tried it with the FileMaker Server yet - but I don't think there should be any issues with that.
Best Regs - The Riceman
Storing Code
Hello Riceman,
Thanks, I like your ideas. We try not to store code on disk but this seems like a good solution when required.
Our next version will include some new opportunities to make code storage easier. Can't comment quite yet...
In regards to running server side scripts, I haven't tried including files but I don't think you'll have a problem.
We've though about adding "pills" for other languages (like Ruby, JavaScript, Perl) but so far, PHP seems to be the most popular with the FM community.
Regards,
Micah
Where to store the PHP?
Hello Bob,
We store our PHP code in a number of places. For short code blocks, we generally put the code directly in a script or sometimes we centralize code by putting it in a custom function (for code that gets called often). For more complex code, we use a special code table and simply call it when needed.
I haven't tried this yet but the new SQL functions in SmartPill 1.5 allow you to select fields data without having to have a relationship. This can save some script steps and keep your relationship graph a bit more tidy. The idea is that you perform an SQL select to get the code (instead of having to set a field to make a relationship, etc.).
Regards,
Micah