Do you use FileMaker plug-in? Why? Let’s try something. Stop reading now, scroll down to the Comments section and answer these two questions. I am seriously curious about your answers. Then scroll back up and read the rest of this article.
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.
How to use plug-ins and stay independent
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.
This approach is better than creating a plug-in free solution from the beginning because you can benefit from the plug-ins power while minimizing the risk of depending on them. Typically, you end up with universal scripts which can work with several different plug-ins and choose the best one currently available. Another benefit you get this way is that when using a plug-in saves significant development time you can simply leave the pure part of the universal script empty and postpone it to the time when you will need it. Which may even never happen if the plug-in vendor is stable enough and keeps supporting the plug-in well.
This version currently provides only one script for displaying a custom message. It can utilize three different plug-ins if they are installed, 24U SimpleDialog Plug-In, Troi Dialog Plug-In, and Kargas Dialog Plug-In. These three appear to be the most used dialog plug-ins according to my poll. You can immediately use the script to prevent support calls as I have explained in my previous article.
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.
