While only hours are remaining for the new SimpleDialog to get released, let me tell you one more story. Back at the time when FileMaker Pro 6 was a hot new product, I attended my first FileMaker DevCon and showed SimpleDialog to other developers. Some of them were really excited. But I was surprised how many developers told me they intentionally avoid using plug-ins. Although there are now many powerful plug-ins available and some “avoiders” changed their minds, the number of people who hesitate to use plug-ins is still high.
Why many developers avoid plug-ins
At the time I am writing this article, preliminary results of my poll show that 36 % developers do not use any dialog plug-in. Even famous developers such as Brian Dunning or John Mark Osborne are advocates of using pure FileMaker techniques rather than utilizing plug-ins, even when it takes significantly more time to develop.
Surprisingly the most common argument for not using plug-ins is not the extra cost. It’s the dependence on a third party product. As a FileMaker developer you already have to depend on FileMaker, who fortunately is a healthy successful company. But dealing with new versions may be a nightmare anyway – remember the migration from version 6 to version 7 or newer. There are still many customers using FileMaker 6 because of this. Many developers also see this as the highest risk with using plug-ins. What if the plug-in vendor quits, or if the new plug-in version is not backward compatible, or if it does not run on a new system? Now imagine what you have to deal with plug-ins from 3 different vendors.
Back at my first DevCon in 2001 I met a developer who had a solution for this already. If I could only recall who it was so I could honor him here. I think he was a genius doing this in the context of FileMaker 6. He used plug-ins, so he could benefit from their power. But he still remained independent. He did not depend on the specific plug-in version, did not depend on the vendor, he even did not depend on plug-ins at all. He could easily modify his solutions to use other plug-ins or to work without plug-ins. He was able to do that in FileMaker 6. Now, with FileMaker 11 you can implement his technique even better and more easily.
His solution is to hook the plug-ins to the FileMaker database at as few points as possible. With a dialog plug-in taken as an example, you simply create a few intermediate universal scripts and then call those scripts as subscripts instead of invoking the plug-ins directly. So when you need to switch to a new version which is not fully backward compatible, or to a plug-in from another vendor, or even to a pure plug-in free solution, the only things you need to modify are the intermediate scripts and custom functions. If you make them modular enough, you can then copy and paste them into all your solutions after being modified, in just a few minutes.
Bonus for you
Not only as an example but also as a source for you, I have started creating a database where you can copy the universal intermediate scripts from and use them right away. You can download a preliminary version of it directly from this page below.
Make your solutions better
Do you still hesitate to use plug-ins? Don’t! Take the chance to make your solutions better without loosing your independence. Use intermediate scripts to minimize the risks. As an extra bonus you will get the power to push plug-in vendors to provide better plug-ins because you will be able to switch them easily.
Then please come back to this blog and share your experience. Let me and my readers know how it works for you. I am looking forward to your feedback.
{ 8 comments… read them below or add one }
I’m NOT using FileMaker plugins. Since I’m not using FileMaker. Never have and probably never will. To be honest, I’m shocked this product hasn’t died decades ago.
Thank you, Mr. HOnza, for the article and for the Independence.fp7 file. I’ve been using FileMaker since 1994, and I DO use plug-ins to extend FileMaker’s functionality, to enhance the solutions I build for clients and to save time. I was reluctant to use plug-ins at first, but once I tried one and realized how much they can do and how easy they are to integrate I never hesitated to use a plug-in that added value to my solutions. ❦
I use FileMaker plugins whenever it makes the most sense for the project. And it makes sense when either there is no other way to accomplish a necessary task, or it saves significant time/money to implement a desired feature.
Now that I’ve read the article HOnza, I can tell you I’m not the genius you met in 2001. However, I did discuss this concept in my 2007 DevCon presentation (“Plunge into Plugins”). My method was to use FileMaker custom functions to implement the plugin calls, but the goal of independence was the same. Using a script is also a fine way to do it. Thanks for the sample file!There is a fairly well-known whitepaper that has circulated for years, giving FileMaker beginners the advice to avoid plugins. This may be a source of much of the FUD.
Thanks for your early comments and arguments for using plug-ins. Tom, good you have mentioned the white paper. I think it has something to do with the famous guys I mentioned
I don’t want to blame their expertise – Brian and John Mark are undoubtedly two of the best FM calc gurus out there.I am curious if I’ll get some comments also from fm devs who don’t use plug-ins. Let’s see…
If anyone is curious why FileMaker has not died decades ago, I can explain that. In person
I hesitated to use plug-ins over the years but now I embrace them when it seems appropriate to deploy a feature to meet a deadline, budget constraint or fill in where the feature is impossible to accomplish with native FM tools. Now… I’ll read the rest of the blog.
Chiyoko, thanks for sharing.