The process got me thinking; it is so simple to understand the well documented FMSA CWP API and build command urls, and it is so simple to use the built-in XML() class in ActionScript 2 to slice and dice the xml FMSA returns, why are all the connectors which exist for interacting with FMSA so relatively complex? I have experience with FX.php, FMandPHP, and FileMakerPHP. For dot net integration with FMSA, there is Wim Decorte's FMdotNET. I also just heard about a brand new, as yet unfinished, open source Flex class for FMSA.
All of these solutions make the problem more complicated by introducing lots of built in features and in some cases introducing a new object class with methods and properties of its own. This just strikes me as unnecessary. Flash, PHP, Flex, dotNet, etc. can readily assemble the simple FMSA command URLs defined in the API, and it goes without saying that they can already do whatever needs to be done once the data is parsed into a structure they understand. So what's up with all the abstraction? Further more, the arrays that many of these connectors give back often need to be massaged anyway, because they generally accept the structure defined in the default FMSA grammar. I think in addition to the impulse to add features and make hammer factory factories, some of these classes are complicated by a backwards compatibility requirements (several support FMS5 and PHP4 for example).
The available XML classes in PHP5, ActionScript2, and ActionScript3, leave little room for improvement in my opinion. I see no advantage to reinventing the wheel, and I see little reason to invent a new class. So to test my theory, over the weekend, I made a single purpose built PHP function called simpleFM which does not suffer from any of these issues. In about 100 lines of code I created a function that includes error handling, and returns a compound query result with an indexed and associative (using recid as a key) version of the resultset data. It is based on SimpleXML functions in PHP5.
It doesn't handle repeating fields (just returns the first rep if it sees one), but that is just a design choice I made. I may decide to change simpleFM to return fields as arrays, but for now I'm thinking that warrants a different function like simpleFMrep(). It also doesn't handle value lists, but why should it? That should be a different function in my opinion. Value lists use a completely different grammar after all. I'll make simpleFMvlist() for that as soon as I need it. simpleFM does handle portals really well. The 2 resultset arrays it returns looks like this:
Or you can access the data by record ID like this:
It also returns some metadata, and the raw results. Here is a complete breakdown of the main query result array:
$query['index']; //compound array
$query['recid']; //compound array
$query['raw']; //compound object
Now that I have come up with the idea for this simplified function in AS2 for Flash, and done a proof of concept in PHP5, my next trick will be to create an AS3 function that creates a dataProvider object for Flex. I'm more conversant in PHP, so I wanted to work out the concept there first, but I have been noodling with Flex already. The main problem in doing this for Flex is that the results need to be reorganized as XML, in a structure that differs from that created by FMSA. The PHP5 function simpleXML() and the AS2/3 funtion XML() convert XML to an object that can be processed with normal property selectors and array iterators. As far as I can tell, in order for Flex to consume an data, it must be re-factored as XML. In PHP5, we have the asXML() function, so I can easily convert an object back to XML like this:
It occurred to me to use a custom xslt on the FMSA, which would return an XML grammar that Flex is able to consume directly, but I have essentially dismissed this idea as being too dependent on access to the datasource. I think the trick for Flex is to handle it on the client side by compiling the parser function into the swf in the same way we already do with Flash. I am confident that it's just a matter of time before I have a similarly simple function in AS3 which returns a Flex dataProvider object from a call to FMSA. Stay tuned, or post here if you beat me to it :)
Update: I emailed a few colleagues and requested feedback. Here's the email I sent :
Hi PHP gurus,
Check out this PHP function I set up.
I posted some thoughts about it on my blog at http://jsmall.us
In a nutshell, the way we connect to FMSA in Flash is so simple and low tech, it got me thinking about why the generally accepted connector classes are as complicated as they are.
So I made a single function that takes care of the main thing I care about, which is parsing out the result. I don't care about all the nifty methods for assembling the command url. IMO, that's easier and more trouble free if you just assemble the command string you need and put in a few variables as needed, and call it a ball game.
Right now, this function returns a pretty verbose result, because it gives an indexed version, an associative version (by recid), a raw dump, and pure xml. The last two are really just in there for development curiosity and possible forensics. But even if they get removed, it still returns two versions of the results for now. I'm thinking of making the indexed version be the default and creating a switch if you want the associative recid version back.
Can you guys check it out and give me some feedback before I offer it to everyone else?
PS: Next I am going to make the same kind of thing to build a dataProvider object for Flex, so any insight relative to that appreciated.