From Dwayne Wright PMP
Certified FileMaker Developer
Please Note: If you are viewing this page in a news feeder, the images may get munged up a bit. For the best experience, please visit the journal directly at http://dwaynewright.squarespace.com/filemaker-thoughts/.
A READER ASKS
I'm a professor trying to set up a wiki-website. The goal is to make it EASY for the public (physicians, patients, researchers) to see treatments and insert their wiki-edits (treatments or feedback) into either one of four categories: Standard, Complementary, Emerging, and Quack.
A webmaster suggested that I use Filemaker or Wordpress to create data files to make the site more user friendly. Which would be better?
Unfortunately, I’m not much of an expert in FileMaker / Web integration. I really enjoy working with FileMaker Instant Web Publishing and have a nice collection of successes in that area. I’ve tried to get into FileMaker Custom Web Publishing and it isn’t that hard. Ultimately, I’ve found that avenue of development unattractive. Some of the things I’ve seen colleagues produce is amazing but I just can’t seem to get into it.
If it were me, I’d explore looking at integrating two different methods to achieve what you describe. The first would be a great web site hosted by squarespace.com and the second would be a FileMaker IWP database hosted by a third party provider.
You can get a free two week trial and there are podcast coupon codes that you can get to lower the price. My site is hosted by squarespace and I’m quite happy with it. I used a code from the podcast “This Week In Tech” and I pay under $15.00 a month.
FILEMAKER IWP HOSTING SERVICE
The quickest and easiest way to put a live FileMaker Pro database on the web. Because of this, there are come design limitations but I don’t think you would run into those in your situation. There are a number of hosting companies our there but I’ve only used “the drooling dog” because Angelo has always taken great care of me.
SOME IWP IMPLEMENTATION TIPS
Users can change their login account and password settings in IWP, if the developer allows them to access a script using the Re-Login script step. This may not work however in some hosted database situations and you cannot setup the ability to automatically have a user change their password.
When IWP users add a new record or edit data in an existing record, they must click a submit button in order for their changes to be saved. This submit button will normally reside in the status area but a developer can add their own button in the FileMaker layout to Commit (Submit) the record.
IWP has a fairly significant number of limitations. Here are just a few of them. IWP users cannot add data into container fields. IWP users cannot spell check data. IWP users cannot use keyboard shortcuts. Some layout objects such as rounded rectangles do not look good in IWP. Always test your IWP views as you design them. You can both edit a database in FileMaker and view it in IWP from the same machine. Leave lots of extra space for fields using radio buttons or checkbox value lists. The same is true for container fields that might be used to play QuickTime movies. Conditional formatting does not work with IWP (as of FileMaker 9).
List view in IWP is limited to showing only 25 records at a time. Table view is limited to showing only 50 records at a time. For this reason, many IWP developers try substituting portals for list view when they can.
Only the Tab key is supported for keyboarding from one field to the next in IWP.
Try to limit field validation in the IWP settings. Every validation error will be returned when the user tries to submit the record. The number of validation error messages can be very annoying.
All Custom Menu settings are ignored by the IWP user.
FileMaker Instant Web Publishing supports more than 70 script steps! When the Indicate Web Compatibility checkbox is checked, all incompatible script steps are dimmed! If a script contains IWP unsupported scripts steps and it is executed under IWP, you can use the Allow User Abort script step to manage the effects. If the Allow User Abort step is in the ON position, the script will stop when it encounters the unsupported step. In the other position, which is the OFF position and the default for FileMaker, then IWP will pass over the unsupported script steps and execute the rest of the script. If there is no Allow User Abort script step in the script, IWP will halt the script at the first instance of an unsupported script step.
My old friend, the Commit Record Script Step, can become even more important in IWP scripts. You may have to sprinkle this step a little more frequently for IWP because of the whole "IWP has got to submit it's data" thing we chatted about earlier.
The Get(ApplicationVersion) function will return FileMaker Web Publishing for the current IWP users.
Since there are no alert messages in IWP, your scripts executed within the IWP act at is the Set Error Capture script step is always ON.
The Open URL script step, in the IWP setting, will perform in a new browser window. The Exit Application script step is the IWP equivalent to logging out and is recommended for ending all IWP sessions.
Test, Test, Test, Test and then Test some more for your IWP solutions.
© 2011 - Dwayne Wright - dwaynewright.com
The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.