[Solar-talk] "Forwarding" Controller

Rodrigo Moraes rodrigo.moraes at gmail.com
Wed Oct 18 21:09:26 PDT 2006


Hi,
I like more and more the flexibility of the "forwarding" constructor
idea. So I went to SitePoint forum to see if I could find anybody
talking about a similar concept. I found that Konstrukt's developer is
a member there, and below I pasted his description which explains very
well how it works. So I ask what you, Solar users, think about this,
and the pros and cons you see in this approach.

rodrigo
-----------------------------

"Most implementations of front controller has an up-front
request-mapper, typically driven by a regex. This strategy has
limitations, as you note. One way to deal with that, is to use a
hierarchy of controllers, rather than a flat stack. The topmost
controller (the front controller) will inspect the first part of the
request uri, then decide which controller to dispatch to. It will then
strip off the "used" part of the uri and pass the remainder to the
next controller. Thie next controller repeats the process, but with a
different logic for deciding who's next. This goes on untill the uri
is no longer, in which case the last controller will handle the
request.

Generating url's is equally flexible - a controller will decide it's
own part of the uri, and then call up the hierarchy to have the outer
controller build on it."

[...]

"A hierarchical controller implementation doesn't have a fixed tree of
execution. It doesn't have a front controller per se either. Instead
there is a root controller, which is the entry point. This root
basically works as a front controller, except that it doesn't decide
the full route of the request - only a partial route. This is the
difference to the two classical front controller implementations. The
root controller will dispatch to the next controller in line. Exactly
how many times this happens, depends on the request. Some may stop
already at the root controller, others may go five or more levels down
before reaching the final handler. So the execution tree for this
design is variable in depth.

For example, let's say we have a concrete request looking like :

http://www.example.org/articles/42/edit

Which might result in a tree like this :

Root Controller
   |- ArticleListController
      |- ArticleController
         |- ArticleEditController

The mapping happens in several steps. The root decides that /articles/
should dispatch to ArticleListController. This controller sees the
/42/ and decides to dispatch to ArticleController. This controller
then sees the /edit/ and dispatches to the ArticleEditController."

from: http://www.sitepoint.com/forums/showthread.php?t=418670


More information about the solar-talk mailing list