The question of separating ‘interface’ from ‘data’ in FileMaker Pro isn’t new. In the pre-7 (fp5 file format) days, a lot of serious FileMaker developers and users debated this issue with rigor. Now that FileMaker Pro 7 has been released, the whole question has gained a new momentum. Here are my working thoughts on the question:

Why separate?
Separation of ‘application’ from ‘data’ is possible, and I think it is a good thing. But it is ultimately an architectural decision hinged on your business requirements. That is, whether or not you separate depends a number of external factors such as the the need to scale, the scope and the risk-tolerance requirements of your solution. At inRESONANCE, we are not in the business of creating end-user software or personal “databases” that store stuff like personal contacts and addresses. We are concerned with solving light-enterprise and large-workgroup problems. We deal with multiple functional domains that frequently share the same data but have domain-based workflow and business logic requirements. And to that end, the value of keeping the shared data “shared” and the application layer appropriate to each domain they serve (and thus separate) almost goes without saying.

Where to separate?
FileMaker 7, for all its wonderful enhancements still has its limitations. For one, the field object is the only programmable object. Well, OK, there are ‘scripts’ but that we have a procedural language to manipulate the FileMaker environment isn’t what I am talking about. What I mean is that you cannot tell layout objects to perform “calculations” like you can with fields. You cannot tell the layout field object to change colors or tell it to change its data bindings because all of that is pre-fabricated for us. This is not necessarily a bad thing. For most FileMaker users, the need to change object bindings programmatically falls into the “who-cares” bucket of consideration.

Why is this important to this discussion?　It is important because at the end of the day, the business of separating presentation-logic from data in FileMaker becomes an exponentially difficult exercise. If you want a word in a field in a portal to turn red as a result of some user interaction, you have to do this at the field level. That is, you have to make the word turn red through some calculation field. I think this is where a lot of the debate has revolved. Can you make that calculation field in a different table? (Is this what people mean by derived-data? I am not sure, please point me to that definition if you get a chance). There is some thought that you could completely divorce fields that have the job of changing the way data looks by sticking it in a different table. But the moment you do that, you have to duplicate and synchronize the data/schema between the ‘pure’ data table and the ‘presentation’ table.

I find this a bit of a nightmare. It starts to mitigate the value of using FileMaker to being with, which in my mind is the ability to focus on representing tasks and user-interaction rather than low-level programing just to make the software work. If that level of separation is really that important, I might consider pulling out RealBasic or VisualBasic.

I am choosing not to fight that battle. Until we have object properties and programmatic access to events, I’d prefer to focus on what I can leverage w/ FM7. So, at this point, i see the separation along the lines of application/business/interface vs. data. I reserve the right to change my mind, naturally but for now, I am building proof-of-concepts (PoCs) that have data files and one or more files for everything else.

In a nutshell, I have two classes of files. Files that make up the database and files that make up the application. I am even considering deploying reporting files to the user that talk to served databases.

Business Logic
One of the really cool things about 7′s ‘enhanced’ (some might say ‘unapologetic’) relational model is that we can stop worrying about file limits and start building applications with relational database support for application/business-logic. These applications can be contained in a single file. Let me say again, our applications can now have relational database support. This is not the same thing as saying that the application talks to a relational data source; I am saying that you can concentrate on building an application and applying the power of relational structures in service of the application itself independent of where the data is stored. For example, navigation crumbs can be stored in a navigation table; user prefs can be stored in a ‘registry’ table with key-value pairs. These kinds of things have nothing to do with the data per se but it has everything to do with how the user interacts with the application. This power extends to business-logic. For example, I can see a workflow table where a FM7 based content management system’s workflow can be tweaked for each customer by just changing workflow-sequences records from entirely within the application.

That said, I’d argue that even in FileMaker 7, it might be difficult to say “all” business-logic can be separated into a different file. (I believe Andy Lecates’ “tier-model” lays some groundwork for this discussion.)

Security/Authentication
One thing I haven’t done much of is deal with security management when you have two or more files that make up the entire solution. I’d love to collaborate/share with those who have crossed this bridge.