MVC and FileMaker, The View

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!