Product was successfully added to your cart.

MVC and FileMaker, The View

By August 27, 2012Development, FileMaker, MVC

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!


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!

Author Court Bowman

Court Bowman has been working with in the IT field his whole life, working as a network engineer, database developer in Oracle and Progress and as a IT director for several firms. He has been working with FileMaker Pro since version 2 and has been a reoccurring speaker at the FileMaker developer conference. Apart from his expertise in FileMaker Pro he has experience in system architecture and design, data modeling and database architecture. He also has years of experience as a process and workflow consultant and has helped with the design and deployment of hundreds of systems in FileMaker and on the web.

More posts by Court Bowman

Join the discussion 4 Comments

  • jsorge says:

    I’m really interested in this. Do you have plans to post the controller article soon? I’m on the cusp of starting a big new project and would like to experiment with MVC. Example files would be hugely helpful as well. Thanks!

  • Mario says:

    I can understand the use of global fields to take advantage of Filemaker’s Custom dialog box, but I’m not clear why you tie those fields to the model (i.e. the parts table) instead of a global table?

    • Mario says:

      Forgot to add, regarding the first part, wouldn’t it be better to just use global variables and a “custom dialog window”

    • Anonymous says:


      Thanks for comments! Our decision to put the global fields into the parts table is just a preference. You could easily put the global fields into one table. For our own organizational preferences, we like to keep related information in the same table, just so it’s easy to understand what is what. However, the sample file here was meant to help illustrate how MVC might look in FileMaker, rather than a complete way of organizing a system.

      As for the choice to use fields over variables. This is since using custom dialog windows don’t allow direct input into global variables, but require global fields to accept the data. The custom dialog was not intended to be the “best” way to get the data from the user, but rather an “example” of one way to get that data. It was intended to show that by separating the view from the model you can get the data any way you want and still process the data in the model the same way using the same code.

      I hope that makes sense and helps. Thanks again for reading!

Leave a Reply

All rights reserved Cleveland Consulting.

Call Now Button