The Model-View-Controller (MVC) pattern keeps code modular by separating the business logic from the interface and data layers; but what if there is information that has no business logic? Then the MVC pattern forces the programmer to write code for all three layers to manage that information even though not all layers need to know about it. I invite comments from others whether it’s worth breaking the MVC (or MVP) pattern, and if so when.
This is very common in content management systems. A template for a content page might have several areas of content to edit: perhaps a banner image, a couple columns of text, and a header. Once the template is written for this page all the programming decisions are pretty much set in stone; for example, when a user wants to edit this page, we provide fields to edit these various pieces of content and when the page is published, convert these fields to HTML and display them in the template.
In a standard MVC architecture, the programmer adds boilerplate code; which requires updates to the database, the administrative interface, and the display logic.
Here’s where “Chunks” come in: A Chunk of data is a typed piece of data which knows how it should behave in all layers. Furthermore, once a template declares a Chunk, the administrative interface and user interface automatically do what they need to do to manage and display the Chunk, requiring no changes to the codebase or to the database. Our most basic Chunk syntax in our Dashboard Framework (http://dashboardwebapp.com/) is:
{chunk for=$content class="ContentPage" label='Left Column' type="tinymce"}
This tells the administrative interface that a TinyMCE textbox is required to edit this Chunk, and that next to that box put the label “Left Column”. In the same line, it tells the ContentPage class that one editable chunk should be associated with each ContentPage object.
Voila! No need to edit any code to change a one-column template layout to a 2-column one with a banner and required H1 header.
Our chunk syntax is quite robust, allowing for:
- Multiple versions (french and english, say) with the edit areas show side-by-side
- Shared Chunks so that a single chunk is displayed on multiple pages
- Preview text to display in a TinyMCE Chunk
- Many types such as tinymce, date, file upload, etc.
- Draft control — each Chunk can have a draft and live version, with full revision history
What all Chunks share in common is that only edits to the template are required, and the administrative interface is auto-updated!
#1 by Erik Kastner at February 6th, 2010
Actually, the chunk thing enforces MVC, it doesn’t violate it. Each chunk is actually a view. Without seeing the implementation, I’d venture that the class that the chunk is calling is the Controller for that view.
#2 by Thurloat at February 6th, 2010
After an exhaustive discussion with @kastner , I have fallen into agreement with him. The idea of chunks is to further separate the presentation layer from the data layer. We accomplish this by having chunks themselves have their own model, view and controller defined directly in the template; which I originally thought was where we broke our MVC.
However what most matters in MVC is that all the presentation is in one place, and that the business logic is not in that place. This concept accomplishes that very principal to the core. It keeps the “BS”/Presentation data away, and our nice clean modules untouched and patchable in the future since each rollout doesn’t require model changes and the such for client specific data. So it sounds like we’re getting closer to MVC’s true concept, not farther.
#3 by Erik Kastner at February 6th, 2010
Building a reusable codebase is a balance between efficiencies. On one side you have execution efficiency. This gets less important as time goes on, unless you end up needing to scale. On the other side you have coder efficiency. This one is the hard one. You need to have abstractions that make sense and are easily understood. What “MVC” gives you is a shared language for introducing someone new into the codebase. However, the term is so bastardized, I think it doesn’t even give you that. As long as someone can reasonably guess where some piece of functionality is, and that is the ONLY place it is, you don’t need to put a label like MVC on it.
#4 by wolfe at February 6th, 2010
Erik Kastner’s comments are right on the mark — thank you!
As for the observation concerning the balance between efficiencies, my experience is that they are seldom in as much tension as one would at first suspect. Coding efficiency leads to centralized functionality which then makes it easier to optimize that functionality (once and for all) rather than separately optimizing each place the same functionality is expressed. Since you get more bang for your coding buck, the execution efficiency gets addressed rather than put off when deadlines are tight.