My top feature request for FileMaker 14 is Multiple Parameters for Scripts. It’s a critical part of building complex apps. It’s not yet satisfactorily solved. Compared to other technical issues that FileMaker has taken on like WebDirect, it’s easy. Yet it’s positive impact on the ecosystem would be huge.
FileMaker Inc. has decided that FileMaker is a platform. Platforms live and die based on their ability to create a network effect. Recently I wrote about what the network effect did for WordPress and how FileMaker could learn from it. To sum it up, we need more people, sharing more code. I believe that the biggest impediment to that, is our inability to have a native, standard way to pass more than one parameter to scripts.
What’s my evidence? Years of arguing, wrangling, convincing and cajoling that has gone on in this community over how to do it best. It maybe the number one topic of discussion at modularfilemaker.org. I know it has taken filemakerstandards.org a couple of years to come up with thiers. Imagine what that energy could have spent on, instead of being wasted over something that should be built in.
As an example, this just came up today on Twitter.
3 of ? -to move from what was unofficially a standard to a new standard which is incompatible seems to break down for me and I see (con'd)
— Drew Sanderson (@fmsimplicity) April 7, 2014
4 of? -strong case for the change. @toddgeist is right with the philosophy to think that modules should not use custom functions for (con'd)
— Drew Sanderson (@fmsimplicity) April 7, 2014
@fmsimplicity ( Drew Sanderson ) is hitting the nail right on the head. “This is a pain with out CFs, yet I don’t want to use somebody else’s”. There is nothing wrong with the sentiment. It’s legit.
Technical Solutions to Multiple Parameters
There are lots of good technical solutions. Some that rely on custom functions. Some that do not. Here is a short list.
- FileMakerStandards.org’s Parameters
- Six Fried Rice – Passing Multiple Parameters
- An old one from me – Using List()
There are many more. Incidentally there is a new way that just became reasonable. I will discuss that in another post tomorrow. It’s interesting but I don’t think it solves the problem completely.
Good technical solutions aren’t always what’s best for a community hoping for a network effect. We need solutions that encourage ways of working that allow us to share. Custom Functions do not, as I have argued before. That is the main reason I support FileMakerStandards.org’s Parameters. You can use that standard without custom functions. I wouldn’t quite say it’s the lesser of all evils. But at least it can be made to work without CFs. But it is not as easy as it needs to be.
Watch out for Anti-Patterns
I have shared my opinion on this with all of the project management team at FileMaker Inc. And while they seem to agree that it is important, it never seems to make the list of new features. I think this is because it seems like it is solved well enough for those who care. The custom function solutions do sort of work. But only in the way that all anti-patterns do. They work at first, but eventually lead you down the wrong path. In this case they lead into fragmentation and fragility. These are exactly the kind of problems that must be solved at the platform level.
Pass it On!
We need the ability to pass multiple parameters to scripts to be a core, native feature of FileMaker. We need it ASAP! If you believe this to be true as well, why not help spread the word? Maybe if enough of us ask nicely, we can get some tractions.
I agree completely. Also it bothers me that something so simple as a search and replace is not possible on the script editor window! And what about line numbers?
well, i hear you Todd, and i’ve been campaigning for the same thing for a while too! 🙂 Since 2009! http://www.harmlesswise.com/0906-filemaker-python-dictionary-list-functions
One thing that occurred to me, however, the dread possibilities of implementation. They come up with a new file format .fp1X, we all have to migrate to it or die. They couldn’t migrate value lists to it, they’d have to maintain that legacy code (which it would become), nothing short of true variable ‘types’ and those would include lists and dictionaries (acc. python) or objects and arrays (acc. JSON) etc.
It’s quite a change!
I can see them keeping their new system simple and clean for newbies and Value List support dying! 🙂 A .fp5 to .fp7 style change! Aaarrghhh! Near death experience… I’m still converting my F5 work project! This concern has only just occurred to me, but i can see the temptation from FMs point of view if they do move to proper objects and stuff like most programming languages, then they might dump value lists to keep it simple. But it’d be a crippler for maintenance of some really huge products that exist out there.
We’d get so much cool stuff from this of course, so ultimately whatever the price, I agree. This is the one critical feature that FM lacks. So powerful in so many ways.
A pretty handy minor would be ExecuteSQL having write powers: UPDATE, DELETE & INSERT!
But as you say, long term change, this is the one that’ll be a platform game changer, so much will come from it.
I concur with Todd that this would be huge and disagree with Thomas about U<D<I methods of SQL. I think it would be way more valuable to have the ability to create, alter and drop table objects
The ability for FileMaker scripts accept script parameters in way that is implemented and managed at a platform level is very important. It would solve a lot of issues in regard to code portability, especially in large deployments.
Also, the ability for ExecuteSQL to do full CRUD on table data AS WELL as DROP/ALTER etc. on DB schema is also important. It would allow mutli-environment (DEV/STAGING/PROD etc.) deployments to better handle upgrades. The ability to script DB schema changes across environments (instead of physically moving files and trying to manage (by which I mean fix) all file access references as well as data imports etc. would be a HUGE boon to FileMaker in the Enterprise.
Apart from this, one of the things I really miss are ‘outside script comments’. That is, when I want to use a script, I don’t want to have to open the script editor to be able to read the description, to read which parameters are needed and which results can be expected. The 100 characters of the script name are almost always to few to describe all this.