08/11/2009 - Building a FileMaker Pro database from scratch can be a daunting task. There you are, staring at an empty field definitions window, wondering where to begin your project. You have a rough idea of the solution you want, so you dive in and start creating fields.

Before long your list of fields has grown and you've added several tables. Perhaps you've tied them together with relationships, and you're designing layouts.

It seems like there should be a quicker way to get your project started. Luckily, there is.

For years when starting a new database project, I would do just what I described above; I'd dive in, creating fields and layouts, slowly spinning my project until I had a nice start on the solution. Sometimes this worked great, sometimes it didn't; it took years of having to retroactively rebuild parts of solutions before I realized a few things that would help in my design process. One of the easiest to implement, and quickest to put together, is FileMaker templating.

Put simply, a template is a rough form from which you hew your project. For example, many artists start a new painting by covering the entire canvas with a wash of a single color; this could be considered a simple template, although we'll take the concept a little farther.

In high school, I learned how to write a speech; I learned to start with an introduction, briefly announce the points I was going to cover, elaborate on each point, and then finish with a stunning conclusion.

In FileMaker Pro I use a similar approach, envisioning the finished product from the very start. Here are the features I want in my template: 1) I want to include those elements that I know I will always use in almost every database; 2) I want to include as many visual elements as I can that will be in almost every project; 3) I want to write some reusable code that I can easily configure for use in any project that I begin; 4) In want to include as many little tools as I can that might help to speed the design process; 5) I want to build my template so that it's flexible and easily adjustable for each project.

A good template is a collection of those tools that you will want to use with each of your future projects; it is an amalgam of all those things that you did RIGHT in previous projects. It might include your favorite button graphics, some elements that you like to use in each project, perhaps some text that is already formatted the way that you prefer. For example, here is a list of what you would find in my current FileMaker Pro database template:

GRAPHICS
Favorite icons for add, edit, delete, and search
Layout elements that I commonly use--engraved rectangles, rounded rectangles, title bars for rectangle sections or tabs;
Snippets of text in my favorite format, in a color that I like to use in m projects; this includes several sizes--header, labels, content, navigation, and so on
A tab control that is already formatted the way that I prefer;
A simple web viewer that shows the current page and foundcount, and which can be used on any layout by simply pasting it onto the layout.

CODE
Fields that I include in every table--creation timestamp, modification timestamp, who modified, who created, recordID, recid (a calc field equal to get(recordid) and which I use for web apps);
A table with the usual contact fields in it (name, address, city, and so on); they're in 90% of the solutions I create;
Custom functions that are a must for every project that I do--at the top of this list is a trio of functions that I use for managing multiple-parameter passing; I also include others, including phone number formatting and some others that I consistently employ;
Script skeleton--this is a set of scripts that I use for database navigation, searches throughout the database, and developer functions. It also includes the script comments that I always put at the top of every project, listing the designer's name, address, and version number;
My own custom tab-management system for navigation--I'll cover this in the next article;

As you can see, the list above represents many hours' work, and wasn't done in a single sitting. The script skeleton, as I call it, has been molded and massaged for many years, and represents my current thinking on database navigation and script management. By including this in every database that I undertake, I save myself hours, and enjoy the luxury of knowing that I have scripts in place that I have used for years and which are rock-solid from years of use and testing.

The well-dressed database should not be a cacophony of color; it should include a basic palette of complementary colors and not stray. Some of my more flamboyant clients might consider it too boring, but over the long run they eventually agree that a consistent and subdued color scheme endures longer and is easier to use. For this reason, a templating scheme works well; with a few changes, I can completely overhaul my template for a new project, going from shades of blue to shades of green with very little work.

Adapting good code from other authors is always a good plan, provided it's done with permission. I use a set of custom functions that were written by many different consultants; using fmButler's excellent Clip Manager I can copy them in and out of other projects, but because they're already in place in my template, much of that work is already done for me.

Some of you might be thinking that it sounds like my databases all look the same. Not so! This is where my custom nav tab system comes into play. Here's what it allows me to do: I paste in 2 graphic elements for my tab style (selected or not selected); I name as many as 12 tabs for my solution (I can change them at any time, rearrange them, remove one). There, I'm done!

Next time I'll talk about my custom tab navigation system that I use; it's easy to use and can be set up in less than 60 seconds for any project.

Get started on your template; take your best database, clone it, keep the elements that you want to reuse and delete the rest. Next time we'll talk about the nav bar template.