Context Switching

Context Switching

The idea is that a website is really just a specialized web service - one that returns HTML, by default. But the same URLs can be told to return the same content in other formats. This means the same actions can be done in different formats at the same URL.

Example

Imagine the system handled something called "Books". The system needs to make sure at least the basic CRUD is handled. We would expect the system to have a BooksController available at /books.

• /books - Handle listing the books
• /books/update - Handle adding and updating the books
• /books/delete - Handle deleting books
• /books/view - Display a single book

We're saying you would expect to point your browser at each of these URLS and see an HTML page. The update URL would most likely display a form for your to fill out details about the Book. When ready you would POST that form back to the same URL, /books/update.

The same BooksController should also work for JSON. If we decided we wanted to write some AJAXy thing to show a popup, have the user type some stuff, and save a Book back to the system, we should just need to write a JSON output format.

The URL, /books/update, would be the same, and would do exactly the same thing. It would read stuff from the POST save the Book, and maybe send some output. Only this time, the output would be JSON.

The joy of this is that the Controller usually doesn't need to know the output format. The output format figured out by the Front Controller. The Front Controller creates the Template, sets the output format on the Template, then hands it off to the Controller to be filled in with Blocks. Controller Actions do whatever it is they're going to do, then they put some Blocks into the Template, and give the Template back to the Front Controller.

So, the JavaScript only needs a way to tell the URL what format it would like back. In this case, say we want JSON back - we pass the format parameter: /books/update?format=json. The Front Controller does the rest.

Why do it this way?

This accomplishes a few things that we've struggled with in the past. First, since HTML is the default output format, it pushes us developers to make sure there's a plain HTML way to do everything in the system. This helps us both ensure accessibility (Section 508) and ensure progressive enhancement. There should always be a plain HTML way to do everything. If the browser doesn't support some fancy JavaScript thing, the error state is still a fully function HTML solution.

Also, it gives us a clear path to random output formats that end users might desire. I can't tell you how many times users have asked for a CSV or Excel file of some page of data they're looking at. This way, we don't have to write any new code in the system, just write some CSV versions of the Blocks being used, and we're done. In this example, they might want a CSV file of all the Boook data. The URL would be /books?format=csv. We just need to write some CSV versions of any blocks being used in the BooksController index function.

Website as Web Service

Over time, we're going to want more random feeds of data in lots of formats. This way, we have a path to provide these without writing a separate web service system. I usually see web applications or websites that read from their web services. A lot of those systems end up doing twice the work. They have to develop a web service, then they have to develop the web application that uses it.