MVC Router Implementations

[kyberfabrikken]

I'm a little late to this party, so excuse me if I reiterate some points, but since my name came up I thought I'd just add a few clarifications.

Having a hierarchy of controllers also opens up opportunities for code reuse. A parent controller could be setting a datasource for a child controller, which means you could have the same child controller work for many parent controllers. I'm sure there are a lot more benefits than this, but wysiwyg or kyberfabrikken would probably be able to explain them better than I could.

One of the things that works well with hierarchical controllers, is that it forms a coherent presentational unit. Amongst other things, this makes for a practical way of managing urls and url-propagated state in a transparent way to the rest of the application. It's a different way of cutting the presentation layer, than frontcontroller + mvc. Controllers (or components, as they are called in Konstrukt) tend to be smaller and control only part of the rendering of the page, while having a tighter coupling between controller and view layer. This means that you can't as easily change the view of your application, without touching the controller layer, but the benefit is that you gain a much tighter control of the http-level interaction. In many types of applications, I find that trade worthwhile, since it makes it easier to create a good end-to-end user interaction. It also does away with some (in some cases) redundant abstractions.

The fact is that in the end it's always one controller and one action that are responsible for the response. So the question is, do you get to that controller/action set in one go or through several steps? In that last case controller A gets the first part of the URL. Can I handle it? No, forward to next controller. That one checks if it has to handle it as well. No? Forward again. Etc etc.

With hierarchical controllers, you can spread the handling out over multiple controllers. In a Konstrukt application, you would usually have one "final" handler, which corresponds to the "action" of Rails. However, you would often have several parent handlers, which add a bit of rendering (Navigation for example) or provide contextual model level access for the final handler. This roughly corresponds to Rails "layouts", except that you're not restricted to one, and it isn't just for rendering the view.

On one side it seems simple to use, but at the same time I wonder what happens if you want to restructure your whole URL scheme. If you have the scheme in a central place, it's easy to change. If it's decentralized, you have to change every part of it.

Since components are completely contextual, it is quite easy to move them around. URLs are generated by refering to the parent component, so when a component is moved the urls will automatically change. In fact, you could use the same component in multiple places in your application at the same time. This is especially useful if you want to combine different applications, that weren't written for each other, because they won't fight over the same global resource (the route). In general, it's a more flexible and modular design; The problems with it is rather that it is slightly more abstracted. As a developer, you can't go to a single place and get an overview of all possible urls in the application.