Ohio FileMaker Development

Over the past several posts we’ve discussed MVC and FileMaker. We’ve talked about why you ought to consider implementing this pattern into your syst

em. We’ve looked at each piece of MVC (model, view, and controller) and how it might work within FileMaker. Hopefully, you’ve seen some of the benefits and practicality of using MVC in FileMaker.

Separation Model

One further little tip here. When you combine the power of MVC with the power of the separation model you get some additional benefits.

The data file can act almost completely as your model. You can keep the file hidden, and when you perform scripts within the file it is invisible to the user (no more hiding off-screen windows or window freezes and layout changes to do the model’s background work). The relationships in this file only have to be the ones that relate to how your model works, and they can usually be kept very simple and clean without requiring the waters to get muddied by relationships for view or control work.

The interface file only needs the relationships that will make the views work properly. If no view of a particular model relationship is necessary, don’t add it. Your scripts can all be contextualized for the layouts in the interface, with no need to worry about the context for model activity.

Example

We’ve talked about giving an example file to highlight some of what we’ve discussed. Well we’ve put a little time and have a sample file ready. It’s a barebones look at how MVC might be implemented in FileMaker. As such, it’s not intended to be a full functioning system. For example, it needs better error trapping and handling. Also, as an demonstration file, the system and it’s functionality is a bit contrived. It’s not trying to show an ideal interface, but rather serve as a platform to illustrate some of the pieces of MVC.

We implemented an abstraction component in our model. This is a set of scripts that does a lot of the heavy lifting for you. It just requires layouts set up for model use (basically having an id name on the object that is the id for the table) and it handles obtaining and resolving context for the model, etc. That isn’t necessary for an MVC pattern, but it’s something we’ve incorporated into some of our systems to make things a bit easier.

So, without further ado, here’s the FileMaker demo file for your MVC enjoyment.

As with any development team, our implementation of MVC seems to improve and get more refined each time we do it. So this is, as they say, a work in progress. We’d love to hear your thoughts on how it could be improved.

Bottom Line

The MVC pattern is something we are adopting here in much of our work. It keeps things more organized, allows us to make changes in one place and have that change work everywhere, and it makes the process of adding functionality simpler. Multiple developers working on the same system can more easily understand what is happening within any given system if they both follow the MVC pattern. It seems to just make sense.

Your Turn

You’ve just completed reading our series on MVC and FileMaker. We tried to make it clear at the beginning that we don’t know everything there is to know about the subject and would love to hear from you. So, it’s your turn again. What do you think?

Last time we examined the view portion of MVC and how that might look in FileMaker. Today we’ll take a look at the controller.

Controller

I like to think of the controller as the middle man between the model and the view. This is th

e place where the pieces get connected.

For example, let’s say you’re building a system that inventories computers and their associated parts. You want to allow the user to add a new part to the list of available parts to associate with a computer.

In this scenario, the controller is the part of the system that takes that request in from the view (who got it from the user as discussed in our last post), and sends it, along with all necessary information, to the model to have that part created. If it doesn’t have all the information it needs for the model, it will go back to the view and have it get all that information from the user, and send it back. Once the model has done it’s work, the controller is notified with the result. Typically, the controller will then tell the view to display the results (if necessary).

The benefit of doing things this way is what is called loose coupling. It allows the model to do things however it wants to, and the view to get and display information in it’s own way, without affecting each other. The controller manages the interaction between these pieces so that the model and the view are not in any way dependent on each other.

So, you can easily change how you get the information in the view (layouts, custom dialogs, etc.), without impacting how you manipulate that information in the model. Conversely, you can change how your model works without impacting how the information is displayed and obtained. The controller, then, is the linkage between them.

Um, FileMaker?

Clearly, the goal of this series of posts isn’t to explain MVC completely, but to show how it might work with FileMaker. It makes sense, then, to see how the controller might function in FileMaker.

In many cases, the layout is acting as the view, getting and displaying information and requests from the user. Sometimes the view is a script that has a custom dialog obtaining information from the user, or something similar. Usually I will create a script to be the controller. The view will call this controller script (or a button will perform the script) with the appropriate information that it needs.

In FileMaker context is important. So I tend to make the controller context specific. That is, I will make a controller script for a specific context, so that it understands where it’s data is to be found. It will then pass the appropriate information to the model so that it can do it’s work (context free) and accept the response (resulting information, success, failure, errors, etc.) and give that back to the view (usually in the form of some view script that handles displaying the data through a layout, popup, etc.).

Typically, I have multiple small controller scripts. The helpful mantra that is out there in the world of MVC discussions is “Fat model, Skinny controller” – meaning, keep your controller light weight and let the model do all the heavy lifting. So I try to keep business logic out of my controllers and put it in the model. That means that my controller scripts are basically connecting scripts. They call the model and view scripts that are necessary to perform the task that the user requested, but they don’t actually perform the task itself.

I Live In The Real World

Yes, we all live in the real world. Theoretical concepts are helpful and important, but when the finger hits the keyboard (or mouse!) – that’s when it gets real. I say that to say this (I love that segue, don’t you?): the implementation of MVC in FileMaker can’t be strict. That is, there is room for interpretation as to what goes where and how things get done.

The most important thing to remember is that MVC is trying to provide loose coupling. The reason for employing it is to make changes and extensions easier by keeping the view and the model separate. Try to keep the controller as that in between piece, it has knowledge of the view and the model while the latter doesn’t understand the former nor each other.

Next Time

Next time we intend to wrap up the series with a discussion of putting it all together. Hopefully, as we’ve gone through the parts, you can see how they connect (we’ve tried to make that clear), but we’ll try to tie any loose parts together (pun intended). Also, we plan on having a small demo file that begins to illustrate some of the concepts we’ve discussed.

Your Turn

We’ve just talked about the controller component of MVC. As we’ve being saying all along, we don’t pretend to have it all figured out and would love to hear your thoughts. So, feel free to let us know by leaving a comment below!

Last time we looked at the model component to MVC and I said that the next time we’d look at the controller. Well, it’s the

next time, and we’re changing things up a bit. But that’s alright, because I am the author after all, and I can do that!

Actually, as I began to write about the controller, it became clear that it would be helpful to go through the view beforehand. So let’s examine the view!

View

The view is the way that the user sees the system. It’s their mechanism for viewing and interacting with their data and business processes. In FileMaker terms this is typically layouts, but it also encompasses scripts, script triggers, value lists, etc.

This part of the MVC concept is pretty much the most straightforward to understand. Simply put, it’s the part of the system with which the user interacts. But, as discussed with the model, sometimes things get confusing because FileMaker allows direct access to the data.

When you are on a layout that has exposed fields in a table that the user can edit directly, you are actually seeing and interacting with the model, view, and controller all at once. The Layout itself is the view, the fields are view objects grabbing information from the model (with permission from the controller, in this case FileMaker security and internal engine) and presenting them to the user. When you click in the field, again the controller (FileMaker internals) gives or denies access to the model and allows the user to edit it.

Why Separate Things?

Wrapping your head around the way separating things out in FileMaker for MVC is useful. Because, often times it’s not just layouts that are the view, and layouts can be containers for more than just the view. Views can also encompass scripts – ones that open windows, open tabs, pop dialog boxes, display lists of info, and so on – these are all view functions. Anything that presents information to or accepts input from the user can be considered part of the view.

What’s most important in using MVC is not whether or not scripts are views, or models. Instead, what is important is the fundamental idea of separating view from model, because often times this sort of separation is very helpful.

For instance, you may want to obtain just one piece of information from the user about something. In this case, you would, most likely, create a view that simply pops up a custom dialog requesting that information. Now let’s say that you want to get some additional information as well for some other process, but this additional process is in just one area of the system, not everywhere. If you’ve mixed the show custom dialog in with the model, that show custom dialog is spread throughout the system and tied to the model.

That’s because in the model, as we saw last time, we want to do things the same way every time to get the same results. However, if you separate the view from the model, then you can freely change the view in whichever section of the system (or throughout the system if you need to share view components) you desire without impacting the model. This frees you to gather and display information in any manner you desire, even differently for different parts of the system, while still getting the same results from your model.

Practicality Please

What we like to do is to allow FileMaker to be FileMaker and control the entire MVC process where it makes sense (giving the user a view, layout, that allows direct entry to the table below). Often times, however, we want to control things ourselves. In these scenarios, what we do is have a set of scripts and layouts that together will present a view to the user and get information back for the controller (we’ll get to the controller, trust me).

For example, let’s say you have a system that inventories computers and their associated parts. You want to be able to quickly add a part to the global list of parts making it available to be associated with computers. We would create a layout specifically tied to global fields to obtain all the necessary information for a new part. Then we would create a set of scripts that will specifically display that layout (controlling the globals as inputs), the layout collects the information, and then the script returns (as a script result) the data it collected (to the controller for the model, but we’ll get into that next time).

This example illustrates a concept of loose coupling. This view, since it is entirely independent of any context, could be called upon to get information from the user from anywhere within the system. It can be changed to get more information, or less information, without impacting the rest of the system. By passing the results to the model, we can then let the model process the information in accordance with business rules and add/update/remove data accordingly.

Next Time

So, next time we will dive into the controller (I assure you, it’s next time, there are no more letters left in our acronym). We’ll see how we connect these two pieces (model and view) together.

Your Turn

You’ve just read about FileMaker and how the view component from MVC fits. Now, we want to hear what you think. As we’ve said already, we don’t claim to have it all figured out, so feel free to leave us your thoughts on the subject!

Last time we spoke generally about MVC and how it might apply to FileMaker. Today, we’ll take a look at one particular piece of MVC, the model.

Model

The model is basically a representation of the objects in your system and the busines

s logic surrounding those objects. Sometimes we tend to think of these as simply the tables in our database, but this is only partially correct. They do indeed involve the tables and fields that make up your database, but it encompasses more than just that. It also encompasses any functionality necessary to create, modify, and extend these objects.

So, for example, if your database is about recipes and you need to add units of measure to your ingredients and allow the unit to change dynamically with new units created on the fly, you could add this functionality to the model of the recipe itself and everywhere you have a recipe, that functionality would be available (as permitted by the controller, but we’ll get into that later).

Let’s Get Real Here

Now, in the world of FileMaker the model is typically going to be the data tables themselves, the relationships that are useful to represent the data model, and the scripts used to create/edit/get/delete these objects, and layouts used by the scripts to manipulate the data (since adding and modifying data requires a context).

In terms of real world use, this can sometimes get tricky. The interface allows users to directly access and modify the data in a particular record and field. In this case we need to think of the layout as the view, FileMaker’s engine and security policy as the controller, and the data within the tables and their relationships as the model.

Many times accessing the data this way is extremely useful. But sometimes we don’t want a user to modify that model data directly. This may be because one piece of information is tied to another piece of data, or something needs to happen elsewhere in the system when that data is changed. Often times this is something of which the user is not aware.

The are various ways to approach this. One way to handle this is through script triggers. When a piece of data is modified on the layout, go do something to modify the other data. There are other techniques that basically accomplish the same thing. And at times this is helpful. But often times it is not. Here’s why.

Spaghetti Anyone?

What if you have that same data visible in multiple areas of the system. What if, in each area of the system, that data appears in a slightly different context? Do you have multiple scripts each modifying the other parts of the data from various contexts as necessary? You can easily end up with multiple ways of accomplishing the same thing.

FileMaker databases can become houses of invisible spaghetti strands connecting data every which way. It can still work, but let’s say that the business rules have changed (uncommon scenario? I think not). Will you remember all the places you need to change the process to accomodate the change in business rules? Maybe. Maybe not. How long will it take you to find everything?

Model It and Forget It… Sort of

Putting all this work in the model has the benefit that when business rules change that affect the model, you can change it in one place and one place only. Then you’re done.

Since you’ve changed the business rules in the model, and because your controllers are always calling the model to do the work (rather than handling it in it’s own way) you can rest assured that everything that needs to get done will get done. And it won’t take you forever to accomplish that.

Let’s Get Practical

Okay, okay, you see the benefits of using a model to handle data and business logic surrounding the data. Now, how does that actually work in FileMaker?

The practical side of what you actually do in FileMaker sometimes comes down to personal preference in development. Nevertheless, here’s how I typically do it (and at the end of our series on MVC, we’ll release a sample file illustrating things).

When it’s possible to use multiple files (and sometimes this is not), one file is used pretty much strictly for the model (the nature of FileMaker doesn’t always allow a completely strict separation, but most of the way). In it I create the tables and relationships that describe the model. Often times relationships are created purely for display purposes, and sometimes this is unavoidable, but in the model file I’m usually focused on describing the data in terms of the objects and their business rules.

I have a set of layouts, not directly accessible by a user, that are dedicated to handling model sorts of things. The layout context is dependent the model functionality for which the layout is used. The layouts themselves are extremely light weight, containing no more fields and objects than is necessary. Some objects have names, which assigns them a meaning within the context of particular model functionality.

I setup a script folder for each entity that I want to model. Inside these folders are the scripts that handle things such as creating, retrieving information, modifying, and removing pieces of the model. The scripts themselves are typically passed parameters that give them all the information they need to be self-sustaining. That is, they can go, find their own context, perform their own actions, all without any dependence on where they were called from (the core of separating model from controller and view).

Setting things up this way, I can call the same model functionality from anywhere within my system and get the same functionality. If I need to change how it works, I make that change to the model (in terms of tables, layouts, and scripts doing the model work), and instantly every part of the system accessing the model gets that new or modified functionality.

For straightforward, simple solutions (a few tables, very little scripting, fairly flat concepts), this is often times overkill. But many of the systems we work on (and probably you too) are complex, with lots of system interaction. Following an MVC pattern allows us to model the business logic once, and use it in multiple places. It also allows us to know that changes made to the model will work everywhere.

Next Time

So, this time we’ve looked at what the model component of MVC is and how it works within FileMaker. Next time we’ll move on to the next letter of our acronym, C, or the controller.

Your Turn

You’ve just read our thoughts on FileMaker and the model portion of the MVC pattern. Now it’s your turn to let us know what you think. We don’t pretend to have all the answers related to MVC and FileMaker, so we’re interested in our take on these things. Feel free to drop a comment and let us know your thoughts!

If you’ve been around FileMaker for a little while you’ve probably come across the idea of the separation model. Basically, this concept says that you ought to separate your data and your interface files. This allows you to change the interface wit

hout having to touch the data file, which can improve subsequent version deployments.

There are other benefits as well, but this post is not about the separation model. Instead, it’s about the MVC pattern. I was familiar with this pattern before attending the PauseOnError conference out in Portland a while back, but after a session with Ernest Koe and Corn Walker of Proof Group I started to visualize how it might fit into FileMaker development. So what is MVC?

What is MVC?

MVC (model/view/controller) is a concept that separates not only the data (model) from the interface (view), but adds one more level of separation – control. The model is where business logic and data reside, the controller is sort of like the traffic cop, taking input and passing it around appropriately, and the view is what finally gets the information to the user and gets input back for the controller. Together these three concepts structure how a system is developed.

MVC is very popular in the web development world and the iOS platform (among others). While these environments allow a more rigid adherence to the pattern, FileMaker is different. That’s because FileMaker blurs the lines between concepts.

Many times this blurring of the line is extremely helpful (think about how much time it took you to put a field on a layout and let the user change the data in that field… other platforms don’t have it that simple). It’s what FileMaker gives us “for free.” But that also means we have to consider how MVC works in the FileMaker environment.

Why MVC?

So the big question is, Why does this matter? And that is an important question. It might be easiest to explain why by asking a few different questions.

One Can Dream

Wouldn’t it be nice if, when looking at a system, you knew that if you made a change in one place nothing else would break? Wouldn’t it be nice if a customer asks for a new feature, you could simply extend existing scripts and leverage code you’ve already developed? Wouldn’t it be nice if business logic changed, you knew exactly where to find that logic (and it existed in one place)? Wouldn’t it be nice if you could consistently control what functionality of the system users could perform?

MVC To The Rescue

These are the areas where MVC helps. By separating out data and business logic into one place, when changes occur you know exactly where to go. You also know that if you change the logic here, you’ve changed the logic throughout the whole system. You no longer have to go hunting through scripts, layouts, and custom functions to make sure you found everything. If you need to control where a user can go and what functions they can perform, beyond what FileMaker’s native security can dictate, you simply alter the controller and know that you’ve fixed it everywhere.

Additionally, if a new developer is following the pattern, then they should be able to more quickly understand what is going on in a system as a whole. Interchanging developers on a system is a useful thing.

So MVC in FileMaker, Really?

If you’ve followed up to this point, chances are you’re interested in how MVC fits into the FileMaker paradigm. Since, as we’ve seen, there is no clear seperation of model, view, and controller within FileMaker, it might help to look at each of these individually. So, in the next few posts, we’ll take a peek and see how each concept relates to FileMaker specifically.

Your Turn

You’ve just read about MVC and FileMaker. Now it’s your turn. We’re interested in your thoughts, so feel free to leave us a comment and let us know what you think. Go on, don’t be shy, it’s easy!