FileMaker – the war continues
Now that I am starting to add some web-visible components to the SIS I am building with FMP, I finally have the opportunity to test-drive what I'm doing. What a pleasure it is to make a Selenium script that logs in, clicks around, types a bit and validates the contents of the web pages!
Of course, the best part of test-driving (albeit in this rather coarse, macro way sans microtests) is that it is so much faster! I spent a few minutes putting the script together. I didn't even bother using Selenium-RC but instead just run the thing straight from the IDE. Then, logging in with the right credentials and doing all the preliminary navigation is done precisely once in my script. I don't have to do that mind-numbing, repetitive work that machines enjoy but I don't.
The test, simple as it is, is a one-click, red/green litmus test. If it's red, I hack around in the gibblies of my app, and click again. Rinse and repeat. When it's green, I refactor a little then check in.
Of course, checking in a giant FileMaker file as an opaque, binary monolith really only has value as a backup. There ain't no way anyone's ever going to do a diff on those puppies. Maybe I should take the extra 5 minutes to generate a new DDR in XML and check that in.
And since you brought it up, refactoring's a larf in FMP. Maybe I'll write a book called "Refactoring to FMP Patterns." In reality, all I actually do is to get rid of any debug fields or relationships I created.
While the scripts seem like an obvious target, the real, hard-core refactoring of scripts is something I have skirted. As I mentioned in a previous post, the overhead of passing parameters into a "sub-script" feels like it outweighs the putative benefits. Maybe there are some tricks that I can come up with... I'll have to think about this more seriously.
Meanwhile, even if we can't do much beyond the basics regarding the size of scripts, we can start with intention-revealing names for scripts and variables. Deep nesting of if's might be reduced by using guard clauses.
Other refactorings might come from the database world. At least that's well-understood! Most of the time it's not much of an issue for the schema itself; it's a question of factoring correctly in the first place, thereby obviating the necessity to re-factor. It's not rocket surgery: normalize the schema. Don't duplicate. Consider whether a 1-1 relationship is worth the overhead of maintaining it. The usual bitrot kinds of things like lousy names of fields and tables are quite trivial to deal with in the FMP world – references are transparently updated.
Layouts, being primarily collections of visual elements, yield to modest refactoring goals like maintainability through revelation of intention. Reduction of duplication by parameterizing the layout is not something I have pursued very rigorously. There is probably room for exploration there. One concern is that supporting such techniques might require introducing temporary tables. I suppose I shouldn't be afraid of that, but the though of copying data back and forth just seems like a lot of heavy lifting, again outweighing the minor inconvenience of duplication. Sigh. Another area I guess I need to delve into a bit more deeply.
Although FMP retains references to internal objects by some means other than their names (so you can, e.g. rename a table and all references to it show the new name), it's possible to delete some objects and leave unused objects in the file. This is where an analysis tool is yer only man. It often takes several passes to get a file "clean", but it's worth it as a regular part of pre-checkin refactoring hygiene.
While writing this, I have noticed areas that might be fertile ground for further XP-oriented study. You'll be the first to know.
Comments:
