I stumbled over the homepage of Trygve Reenskaug, the inventor of MVC yesterday. His page on Model-View-Controller is well worth a visit, particularly for the original documents from Xerox Parc outlining the pattern.

It's bothered me for some time to hardcode URLs in my views. It means that if I want to revise the linking structure, I may need to modify the views in a huge number of places. At the same time I don't like the thought of putting it in the model either.

In the entry Enforcing Strict Model-View Separation in Template Engines I point to an interview with, and a paper by, Terence Parr that articulated this issue much better than I had fleshed it out in my mind.

He also proposed a solution: Introduce an extra layer - Renderers - that turn model objects or attributes into a displayable format. An example might be formatting a date string the appropriate way.

His work is centered on Java, and so the solution he proposes (see section 8.1 in his paper) is suggesting having the controller wrapping attributes of the model in separate objects. This is clearly the most flexible solution, in that it allows different controllers to provide different renderers, or use different renderers at different times.

How does this apply to the URL issue? It would be trivial to wrap model objects with a renderer who knows how to turn the model object into a URL referring to it. As an experiment I tried extracting the URL's for the Ruby app running this blog, and it showed me two things:

• It's certainly doable.
• It's a useful exercise even if I ultimately don't make the change, in that it exposed areas where I clearly hadn't thought the linking structure through very well - especially it made me notice areas in my admin code that could be made far more restful and consistent.

A nice thing with Ruby, though, is also that while you lose some flexibility if you don't wrap the objects, you can achieve much of the same separation by reopening classes. Meta-programming techniques and DSL techniques also means that you could make it very easy to add this type of functionality in a way very close to aspect oriented programming, containing all the URL generating code in a single location.

Which lead me to think that it would be nice if I could combine this with my routing, but I'm not sure if that'd be good or not - it would lead to intermingling concepts relating to the controllers and the model.

Does the URLs even belong tied to the model, and not in the controllers?

It's a tricky situation. On one hand, the controllers should handle the overall interaction. On the other hand, in all the web applications I've worked on the systems have been very data centric, and URL schemes have always revolved around the model. REST also favors a data centric approach.

But this is less of a problem than it might seem at first if you first employ separation of concerns by clearly handling the URL formatting either in a separate renderer class or as a separate aspect of the model classes through reopening the classes.

Especially if you pass a renderer (or wrap the model objects that gets passed to the view in a renderer object), the controller remains in the driving seat completely. Imagine an API like this for the view:

renderer.url(some_model_object)

Interesting opportunities does open up to tie this to the routing and still relatively loosely couple the classes. In fact, I would argue that a method like this reduces coupling between the controller and views: If you put URLs in your views, and you change the routing or what aspects are handled by what controllers, the URLs may change and the views may have to change with them. Contain the URLs in a rendering object passed from the controller, and you centralize those changes.

If the routing mechanism is designed to do it, it could conceivably provide a rendering class if the routing information is extended somewhat. On this blog "/tag/(.*)" maps to the Tag model class, and the (.*) group refers to the "name" attribute of the Tag model. If the router instead of mapping /tag/(.*) only to a controller, also contained the knowledge of which model and attribute the static and dynamic parts of the URL map to (if any), then the rendering could be automated.

Arguably, the router is part of the controller infrastructure (technically you'd call it a front controller) and centralizing limited knowledge of the model there is not a big concern, as long as this knowledge is provided by the application and not encoded in the routing component itself.

To take an example from my current router for this blog, suppose I turned this:

  map '/tag/(.*)',      C::TagController
  map '/(.*)',          C::ShowItem

.. into this:

  map '/tag/(.*)',      C::TagController, M::Tag, :name
  map '/(.*)',          C::ShowItem, M::Item, :url

.. to denote that our hypothetical renderer should turn renderer.url(some_item_object) into "/#{some_item_object.url}" and renderer.url(some_tag_object) into "/tag/#{some_tag_object.name}"

An alternative would be to change from straight regexps to something requiring a bit more parsing:

  map '/tag/{M::Tag.name}', C::TagController

... which also opens up the possibility of passing an already instantiated model object in to the controller. The downside of that route is that it requires the dispatcher to know how to create model objects, which either means it needs a factory or it would become tied to a specific mechanism for creating model objects. WIth that choice in mind the earlier syntax example seems more attractive - you trade a little bit of simplicitly in the routing for a whole lot reduction in coupling.

This is a great article on the importance of a clean separation of models and views (see Model-View-Controller).

More people are getting exposed to MVC with web applications programming, but not everyone are making it a clean separation. Much of the benefit of MVC comes from making sure all logic is truly isolated. The article - an interview with Terence Parr, creator of ANTLR and the StringTemplate library - is interesting, but it's the paper referenced at the end of the article that really makes it worth it: "Enforcing Strict Model-View Separation in Template Engines"

I must admit I have sinned in this respect too and relaxed separation more than I should. It is extremely tempting to relax the rules and do what amounts to computation of business rules in the view. The sins may seem small - it's only a matter of encoding some minor rule here and there. But it adds up, and before you know if you need to change a rule and are chasing all over the place.

My first major web app, a Webmail application that we scaled to about 1.7 million accounts back in 99/00, used strict separation, very much in keeping with Terence Parr's points. I built a template engine that specifically only allowed variable substitution, list iteration/expansion, and simple if/else with boolean values. It was a design choice, and one that was constantly fought by the engineering team, probably in part because I was not good enough at explaining the value. At the end of our use of the system (before we sold off the e-mail system) a couple of the guys even made a version that allowed them to embed Perl in the templates, completely circumventing the design goals.

Later, I've used more powerful solutions such as XSL templates, with part of the intent being that a lot of the bad logic is incredibly hard to do in XSL, so (the theory went) people would hopefully avoid doing it and handle the logic in the model where it belonged (though the separation in the code might have been ugly and badly managed). It didn't work. The templates grew incredibly complex because people insisted on trying to shoehorn logic into the templates that didn't belong there.

Terence Parr's notion of a separate "Renderer" layer - in StringTemplate's case using toString() to contain logic relating to the formatting of a single attribute - is interesting, and would likely have done a lot to clean that code up. He also has a good solution to the one value - multiple renderings problem: Wrap the objects in objects handling the rendering.

I'll certainly take a close look at StringTemplate and see whether it's reasonable to make a Ruby-ish version.