SitePoint Sponsor

User Tag List

View Poll Results: Page Controller or Front Controller

Voters
62. You may not vote on this poll
  • I use the Page Controller

    20 32.26%
  • I use the Front Controller

    42 67.74%
Page 1 of 2 12 LastLast
Results 1 to 25 of 48
  1. #1
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Page or Front Controllers, Which do you use

    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

  2. #2
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    Last edited by Ren; Jan 20, 2006 at 05:11.

  3. #3
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I primarily use frontcontroller, but occasionally I'll whisk a simple pagecontroller up. Depends on the job really.

  4. #4
    SitePoint Enthusiast Buddha443556's Avatar
    Join Date
    Apr 2004
    Location
    FL, USA
    Posts
    87
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    Simple fool to the 3rd include.

  5. #5
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  6. #6
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 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.
    Hm ... I don't see the connection ?

  7. #7
    SitePoint Evangelist
    Join Date
    Mar 2005
    Posts
    423
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  8. #8
    SitePoint Addict
    Join Date
    Apr 2004
    Location
    Melbourne
    Posts
    362
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren
    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.

  9. #9
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tanus
    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

  10. #10
    SitePoint Member
    Join Date
    Sep 2005
    Posts
    6
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    We use a front controller for our backend systems, but we use page controllers on the frontend websites to keep it lightweight for speed...

  11. #11
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  12. #12
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?

  13. #13
    SitePoint Enthusiast
    Join Date
    Aug 2005
    Location
    Santa Rosa, CA
    Posts
    67
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    Willowgarden: rapid application platform for PHP 5
    xajax: fast and easy PHP Ajax library
    Web software architecture blog: The Idea Basket

  14. #14
    Non-Member
    Join Date
    Jan 2006
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  15. #15
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  16. #16
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dream.scape
    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.

  17. #17
    SitePoint Evangelist
    Join Date
    Mar 2005
    Posts
    423
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  18. #18
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 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.
    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.
    Last edited by kyberfabrikken; Jan 23, 2006 at 11:47. Reason: As 33degrees pointed out, I was even adding to the confusion with my wrong use of handler. I have corrected the terminology, so it should now match the vocabulatory if Fowler.

  19. #19
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    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:

    Quote Originally Posted by Martin Fowler
    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.

  20. #20
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  21. #21
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    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.
    Last edited by 33degrees; Jan 23, 2006 at 14:36. Reason: Added paragraph about using the term handler

  22. #22
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  23. #23
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    Last edited by 33degrees; Jan 23, 2006 at 22:56. Reason: spelling...

  24. #24
    SitePoint Evangelist
    Join Date
    Mar 2004
    Location
    Fort Lauderdale
    Posts
    522
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?

  25. #25
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Code:
    index.php?mod=list&who=users
    That is the Front Controller; It'd select the correct controller based on a Request, yes


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •