Page or Front Controllers, Which do you use

[Dr Livingston]

Hello,

I was wondering what the consensus was on the use of the Page Controller and the Front Controller.

Care to vote which option you take? What advantages or disadvantages have you found within your own context, of the choice you made. I'm not so much asking the advantages or disadvantages between these two patterns as such, but more what you've learnt by the choice you made.

For example, did you find initially you made the right choice? Or did you need to think again, etc

Lets hear your views everyone

[Ren]

Currently, just been using PageControllers so far.

Recently been experimenting Ruby Routes style FrontController, but looking at Rubys routes I think it may not have gone far enough, in that its limited to only using the path, but see no reason why cant do something similar with the domain too. (eg http://ren.multiuserblog.com). So back to thinking about design for abit.

[kyberfabrikken]

I primarily use frontcontroller, but occasionally I'll whisk a simple pagecontroller up. Depends on the job really.

[Buddha443556]

Started out using Front Controllers and learned PHP only does one request at a time. Now using Page Controllers to tackle one request at a time.

[33degrees]

IMO any suffiently complex app ends up having a central point where common tasks are handled, and often using page controllers ends up giving you a front controller with multiple entry points. But probably the main reason I prefer front controllers is that page controllers tend to tie your urls to your filesystem, whereas a front controller with a good routing system lets you remap your urls at will.

[kyberfabrikken]

Started out using Front Controllers and learned PHP only does one request at a time. Now using Page Controllers to tackle one request at a time.

Hm ... I don't see the connection ?

[skinny monkey]

for very simple pages with submenus that switch the content, i'll use a page controller - no need to overcomplicate things for the sake for it. For administration or login areas, i always use a front controller.

[Tanus]

Currently, just been using PageControllers so far.

Recently been experimenting Ruby Routes style FrontController, but looking at Rubys routes but I think it may not have gone far enough, in that its limited to only using the path, but see no reason why can do something similar with the domain too. (eg http://ren.multiuserblog.com). So back to thinking about design for abit.

One way I've seen things done is that each 'model' instance has a unique url assigned to it (which takes into account the domain name). Then the routes that determine the action is appended to the end of the url, so you might end up with something like

http://mydomain.com/books/a-e/dark-tower/edit

or

http://mydomain.com/books/a-e/dark-tower/delete

etc. A db lookup is done on the URL to find out the ID of the item you're editing, then the appropriate action performed.

[Ren]

One way I've seen things done is that each 'model' instance has a unique url assigned to it (which takes into account the domain name). Then the routes that determine the action is appended to the end of the url, so you might end up with something like

http://mydomain.com/books/a-e/dark-tower/edit

or

http://mydomain.com/books/a-e/dark-tower/delete

etc. A db lookup is done on the URL to find out the ID of the item you're editing, then the appropriate action performed.

I quited like just extending the url pattern idea of Routes. But have to have a method of specifing the latter part of the domain, explicitly having routes bound to a specific sub-domain seems a bad idea.

So instead of http://$user.multiuserblog.com/$year/$month/$day need something like http://$user.%baseHost/$year/$month/$day

[paul_lomax]

We use a front controller for our backend systems, but we use page controllers on the frontend websites to keep it lightweight for speed...

[lastcraft]

Hi.

I didn't think much of this poll when I first saw it, but now I'm genuinely surprised by the result. I was sure the page controllers would just pip the front controllers. I really am out of touch on this MVC stuff.

yours, Marcus

[Dr Livingston]

I didn't think much of this poll when I first saw it, but now I'm genuinely surprised by the result.

You didn't think much of it eh?

[JaredWhite]

I use both. Seriously -- I use an index.php Front Controller (hidden via mod_rewrite) but my request handling code finds the appropriate Page Controller to load on the filesystem based on the URL. So, for example, a URL like:

http://www.mysite.com/category/books/view/234

Would map to a books.php file in the category folder of the site root dir, the view event would be called for the controller object, and 234 would be passed as a path parameter.

Jared

[dream.scape]

Where is the both option?

Forgive the ignorance, but if you've got a Front Controller, don't you then (almost necessarily) have Page Controllers that the Front Controller delegates the specific request to, especially in web applications?

Just surfing around, I found this at the end of an ONLamp PHP article:

The Front Controller specifies where to go (the page to fetch for the requested URI), while a Page Controller decides what to do (the action to perform).

...

One reason to use a Front Controller with a Page Controller is to minimize the duplicated content in the extracted view pages. The Front Controller can set up common menu bars, footers, and so on, while the Page Controller will handle the specific request.

And that is precisely how I work.

[Dr Livingston]

The Front Controller can set up common menu bars, footers, and so on,

That responsibility would be lower down in my view, proberly something such as an Application Controller for example? The Front Controller shouldn't know about making decisions such as the choice of menu, based on the user as one example...

As for not having the option to select both, it is pretty much certain that when you implement a Front Controller, you'd have to implement a Page Controller anyways, but the real purpose of the poll is to find out the consensus of those who bypass the Front Controller altogether in any case

[33degrees]

Forgive the ignorance, but if you've got a Front Controller, don't you then (almost necessarily) have Page Controllers that the Front Controller delegates the specific request to, especially in web applications?

The terms Front Controller and Page Controller refer to different patterns for handling requests; they don't refer to the scope of what they're controlling, and are mutually exclusive. The Front Controller pattern includes both the single object that is handling the request, which is called the Handler, and the objects that the Handler delegates to, which are called Commands. Traditionally, each Command object handles a single action, but the pattern can be simplified by grouping multiple related actions into a single object, which is what I believe you're refering to as a Page Controller; to avoid confusion, I usually refer to these objects as Action Controllers.

[skinny monkey]

maybe somone would be kind enough to post an example (or a link) or how a front controller delegates to page controller?
I think i might need to brush up on my concepts a bit.

[kyberfabrikken]

maybe somone would be kind enough to post an example (or a link) or how a front controller delegates to page controller?
I think i might need to brush up on my concepts a bit.

As Fowler uses it, the pagecontroller and frontcontroller are mutual exclusive - You either have a pagecontroller or you have a frontcontroller.

The source of the confusion is that the frontcontroller works by delegating control to a handler command. And this handler command is almost the same as the page in the pagecontroller pattern. The only difference is that the pagecontroller is the entrypoint of your request, while the handler command gets selected by the frontcontroller (which is the entrypoint). So you might say that the pagecontroller is a handler command, which can be executed directly, while in the frontcontroller pattern, the handler command gets selected by the frontcontroller.
Or put in other words - The pagecontroller combines the roles of handler command and entrypoint handler, while the frontcontroller split them up into separate objects.

To further the confusion, what from one perspective may look like a pagecontroller, may also be percieved as a frontcontroller from another perspective. For example, if you see apache as part of you total application, you might argue that apache is your frontcontroller, and each php-page is a handler command.

You will btw. often see the term action used in lieu of handler command.

[33degrees]

So you might say that the pagecontroller is a handler, which can be executed directly, while in the frontcontroller pattern, the handler gets selected by the frontcontroller.

This is incorrect, it's the front controller that is the handler, and it selects the command; in Fowler's own words:

The Front Controller consolidates all request handling by channeling requests through a single handler object. This object can carry out common behavior, which can be modified at runtime with decorators. The handler then dispatches to command objects for behavior particular to a request.

[Dr Livingston]

This object can carry out common behavior, which can be modified at runtime with decorators. The handler then dispatches to command objects for behavior particular to a request.

That given handler btw, from what I can tell from Java patterns blueprint, is the Application Controller; I pointed this out earlier I believe?

That given handler could I suppose, act as just about anything you'd want, such as playing a part in some sort of router...

There is nothing written in stone in that regards.

[33degrees]

That given handler btw, from what I can tell from Java patterns blueprint, is the Application Controller; I pointed this out earlier I believe?

Front and Page Controllers are types of Input Controllers, and that includes the Handler, which is so named because it handles the actual request. In both Fowler's terminology and Core J2EE Patterns, an Application Controller is a different type of controller, containing logic for flowing between steps in a multi step process, like a wizard; it sits in between the Handler and the Commands/Views/Actions.

I think it's best to avoid using the term handler, because in the general sense of the word, many parts of the controller hierarchy handles something, so the term is confusing.

[Dr Livingston]

Yer, that makes more sense I suppose, but going by that then, I would think that in my case, I have therefore forgone the handler it's self. So, do we have something like this then...

Front Controller --> Handler --> Application Controller -> Action/Command;

I would think that the use of an Application Controller is optional as well

[33degrees]

It took me a while, but I finally managed to track down an article referenced by Fowler called Objects and the Web, which talks about MVC as applied to the web. In it, they describe an architecture like:

Input Controller --> Application Controller --> Action (Command)

Where there is a single Input Controller, but multiple Application Controllers and Actions. They then go on to say that the logic contained in the action can be made a method of the Application Controller, improving encapsulation, and giving simply:

Input Controller --> Application Controller

Which happens to be my preferred architecture, and an increasingly popular one.

[photo312]

what is the difference between Front controller and Page controller.

Is Front controller the code that calls on other code based on the task at hand? For example index.php would serve as the starting point for an application and depending on the $_REQUEST array content it would perform different actions?

index.php?mod=list&who=users

or is this a Page controller?

[Dr Livingston]

index.php?mod=list&who=users

That is the Front Controller; It'd select the correct controller based on a Request, yes