Controllers

Chip’s Controllers

Controllers act as the mechanical interface between a model and view. They define a scope for that view which can be as granular as a single button, or as broad as the entire application itself. Once a controller is bound to a view, all interactions between the view and model remain within that scope. This pattern allows complex applications to remain modular and free of cross-contamination of data, actions, and states.

Banking on Chip

One way of looking at the relationship of the model, view, and controller is a bank.

A bank is a physical structure (view), containing data (model). In order to get into the bank, the bank manager has to show up and unlock the doors (controller).

In a Chip application, we can liken the physical bank building to our template. For the most part, it’s a shell for user interaction. It has some predefined logic to it, like business hours, and who can access which parts of it, but it’s really just a building.

Banks store all sorts of data. Customer info, currency, documents, Meemaw's pearl necklace - whatever. This data and the systems that control which data is retrieved and when, make up our model layer.

Having a building to hold peoples' things is no good without a means of getting those things in and out of the building. The building has hours, but someone has to turn the key in the morning. Someone has to decide how many tellers to schedule and which windows are open. Someone has to decide if the customer needs to speak with a banker one on one and direct them to the right person. We need janitors to keep things tidy, security guards to enforce the rules, and someone to make sure the pens are chained and deposit slips are stacked high. This overseer of the exchange between the customers and their data within the confines of the building is our controller.

Nesting

In keeping with our banking analogy, we can take controllers in Chip a step further. We can nest them! Because a controller is attached to a view, we can have as many views within views as we want. Just like the bank that has a physical structure for your data transactions, and a mechanism in place to make transactions possible within that structure, we also have a physical structure within, where we can lock away our valuables. The vault! The vault comes with its own set of rules and procedures. There may even be two vaults, both identical, with different combinations. Chip gives us the ability to add as many vaults to the bank as we want, and ensure the things we want to remain the same between them (like it’s physical structure, which way the door swings, and how it’s attached to the floor) stay the same, and the things we don’t (like the combination or whether or not it’s even open) remain different.

Want more? How about this: Inside the bank, there’s a vault, and inside the vault there are safety deposit boxes. Inside one of those boxes is a suitcase. In that suitcase, an envelope, and in that envelope, various passports and currencies that allow our hero the means to slip between countries, evading anonymous government agents, on his quest to find his real identity. The controller isn't the container or its contents - it's the key turn, the latch flip, the lid lift, and the swipe of the letter opener that allows our rogue sleeper agent to interact with his data. It lives in the space between the model and view, holding the them (and thus, the application) together.