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 2 of 2 FirstFirst 12
Results 26 to 48 of 48
  1. #26
    SitePoint Evangelist
    Join Date
    Mar 2004
    Location
    Fort Lauderdale
    Posts
    522
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    and what would a page controler do that would be different from the above concept?

  2. #27
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, it'd proberly do whatever you wanted to do, ie

    Code:
    www.somesillydomainname.com/products/bathrooms/
    With that URL you would list all bathrooms available, and nothing more; The Page Controller would generate a list of available bathrooms for you... You'd basically just have the required script to do just that and nothing more.

  3. #28
    SitePoint Evangelist
    Join Date
    Mar 2004
    Location
    Fort Lauderdale
    Posts
    522
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    so if I may - what is the difference between using the two. What is the benefit of using a front controler, vs. page controler? And - I am assuming that they are part of a MVC strategy. Am I correct?

  4. #29
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Umm...

    I wouldn't say off hand, that either the Page or the Front Controller specifically are actually part of an MVC architecture, as such, but it's just that MVC works better in most views, with either of the patterns; You don't have to implement MVC to use a Page or Front Controller, in other words.

    As to the advantages and disadvantages of either pattern, that is why I started this poll I too wanted to know more about the experiences regular members have had with these patterns...

  5. #30
    SitePoint Evangelist
    Join Date
    Mar 2004
    Location
    Fort Lauderdale
    Posts
    522
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So for example, if I have a website that serves:
    1. guests,
    2. clients,
    3. trainers -
    I would set up a front controller that based on the usergroup logged in - loads a different php file that has code for that specific user group. From then on, I would use a page controller that performs deletes or updates or other operations that that group requires.

    Would that be correct?

  6. #31
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by photo312
    So for example, if I have a website that serves:
    1. guests,
    2. clients,
    3. trainers -
    I would set up a front controller that based on the usergroup logged in - loads a different php file that has code for that specific user group. From then on, I would use a page controller that performs deletes or updates or other operations that that group requires.

    Would that be correct?
    No.

    Front and Page controllers are Web design patterns. They are generally similar in that they perform the same function; the actual implementation is slightly different.

    Look at it like this: each time you call a Web URL, the server starts a new "application", its result being the HTML ending up in your browser. With FC, it's always the same application -- a single "entry point" where your application does the routing and calls the actual code you need. With PC, this routing is delegated to the HTTP server, using different URLs to start different pieces of code. And by URL is not meant whatever you send to the server, but what the HTTP server receives and fires up. So, the example in a previous post could work with both FC and PC -- it's just that in the first case it would have to be rewritten or otherwise redirected to the central application entrypoint URL.

    Simplified, all (actual) URLs for a FC would look somewhat like http://www.example.com/index.php?page=guests, while for PC you would have several entry points with URLs like http://www.example.com/guests.php.

  7. #32
    SitePoint Wizard
    Join Date
    Jul 2004
    Location
    Minneapolis, MN
    Posts
    1,924
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I use PageControllers, but I think I may move into using FontControllers because I think in many situations they are more beneficial. I am working on a basic framework for my future applications and I plan on using a FC instead.

  8. #33
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    Simplified, all (actual) URLs for a FC would look somewhat like http://www.example.com/index.php?page=guests, while for PC you would have several entry points with URLs like http://www.example.com/guests.php.
    Couldn't "http://www.example.com/guests.php" be a Front Controller serving up a Page Controller for guests? I'm not sure I'm seeing a distinct difference with the example above.

  9. #34
    Put your best practices away. The New Guy's Avatar
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    2,087
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    I am correct in saying that the frontcontroller method requires mod_rewrite to work?
    "A nerd who gets contacts
    and a trendy hair cut is still a nerd"

    - Stephen Colbert on Apple Users

  10. #35
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by The New Guy
    I am correct in saying that the frontcontroller method requires mod_rewrite to work?
    Nope. That's just for URL beautification.
    Quote Originally Posted by mwmitchell
    Couldn't "http://www.example.com/guests.php" be a Front Controller serving up a Page Controller for guests? I'm not sure I'm seeing a distinct difference with the example above.
    You're absolutely correct. The example was simple by intention, but very illustrious if approached right.

  11. #36
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mwmitchell
    Couldn't "http://www.example.com/guests.php" be a Front Controller serving up a Page Controller for guests? I'm not sure I'm seeing a distinct difference with the example above.
    Well, yes, naturally, it depends on your overall application design. If you have, say, index.php for regular users and guests.php for guests, that would effectively make it a separate front controller; if you have a page that lists guests called guests.php, page that lists members called members.php etc, then you have a bunch of page controllers.

  12. #37
    SitePoint Evangelist
    Join Date
    Mar 2004
    Location
    Fort Lauderdale
    Posts
    522
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I am finally understanding it. Wow. Great forum.
    I was thinking about it just like that - separate front controller for user groups such as guests, clients and trainers.

    And I did notice mod_rewrite used numerously for a front controller. I might also ad that using a front contoller is an additional way to hide the real directory path and one might call the FC as the INTERFACE to the system.

    Would the term INTERFACE be an exaggeration?

    THanks
    Last edited by photo312; Jan 27, 2006 at 10:30.

  13. #38
    SitePoint Enthusiast
    Join Date
    Jan 2006
    Location
    Amsterdam
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I was wondering how I actually represent page structures while using Front controllers (or really: where and how do the navigation menus get generated and where do I get the structure from)? Maybe this a CMS specific question?
    Thanks,

    Nikolai

  14. #39
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    where and how do the navigation menus get generated and where do I get the structure from
    Not from the Front Controller in my view, proberly from a lower layer, that would decide how to build the navigation structure...

    Say you have a number of groups, ie Administrators, Publishers, and Authors within an CMS environment yes?

    How the CMS operates, depends on group membership, doesn't it? The navigational menu is just one component, dependent on the user and their group membership; Administrators have more options than an Author would have for example.

    How I generate the navigational menu at the moment, is dependent on the logged in user, and their group; Each menu link is actually a Composite it's self, within a (larger) Composite structure; Each Composite is therefore, only attached to it's parent Composite if the link the Composite represents, is valid for the group the user is assigned to, and if there is an action with that link, ie

    Code:
    http://localhost/admin/index.php?module=calendar&action=create
    The logged in user, has the privelege to carry out that action. Anyways, back to the point that there are a number of different groups? Such groups have dependent views, an Administrator view is different from an Authors view, so I use a Strategy which is passed into the required Composite Controllers constructor.

    I could decorate the Controller in question, but from experience, I believe a Strategy offers more flexibility, and is looser coupled, in the context of what the responsibility of the moment is; There are a number of Strategies, trying to implement those via Decorators would be less flexible.

    Hope that gives you some thoughts?

  15. #40
    SitePoint Enthusiast
    Join Date
    Jan 2006
    Location
    Amsterdam
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Wouldn't it be good though to have the front controller be coupled with delivering some sort of sitemap for menu creation? Since the front controller is the only one knowing what to do with the request it gets, it kindof knows about the internal site structure doesn't it?
    Please tell me if I'm going in a totally wrong direction
    Each menu link is actually a Composite it's self, within a (larger) Composite structure;
    How do you define the structure of pages and child pages or how do you add a new menu entry to another class or module? Should I have some sort of Sitemap in XML format? Then I run danger to get a way to big file if my site has a lot of pages.. I am wondering because I want to combine say a CMS which clearly works with pages or sitemaps and a e-commerce application which I can perfectly run using a front controller or so.

    Until now I had actual pages in a DB with left_id, right_id and a level field. Each page had an XML definition which then controlled which Classes got loaded. That made menu creation pretty easy and fast.
    Thanks,

    Nikolai

  16. #41
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by NikJazz
    Wouldn't it be good though to have the front controller be coupled with delivering some sort of sitemap for menu creation? Since the front controller is the only one knowing what to do with the request it gets, it kindof knows about the internal site structure doesn't it?
    Please tell me if I'm going in a totally wrong direction
    Not totally.

    The problem here is that not all pages your Front Controller should be aware of will appear in the navigation. For example, if you have a contact form there should be a navigation entry to it; however, the thank-you page that appears when a form is sent should not be in the navigation.

    Also, you may have the "convention over configuration" approach similar to what is used in Ruby on Rails, where an URI of the form http://www.example.com/test/page is translated into a call to the page method of an object of test class.

  17. #42
    SitePoint Enthusiast
    Join Date
    Jan 2006
    Location
    Amsterdam
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the reply! I am still a little bit in the dark as where I actually get the page structure from. Until now I used to store a page tree in a DB which was quite fast. Using a front controller, this step is taken out.
    But what if I have dynamic menus - say through installed extra classes (plugins)? Where would you register their menu behavior and display level? Also I wonder where in the MVC model this would belong to? would it be part of the view?
    Thanks,

    Nikolai

  18. #43
    SitePoint Evangelist
    Join Date
    Mar 2004
    Location
    Fort Lauderdale
    Posts
    522
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    To understand this, I would suggest you do not treat the menu as a menu, but treat it as just another "thing" you are trying to control based on the user logged in. I would assume that not only you have to specify different behavior for the events that take place for different users, but also assign different permissions to those events.

    A great book talks about this : "Professional PhP5" - in the chapter "Event-Driven Programming" they touch upon the concept of different "Functions" being run under a secure environment or not.

    SO you'd have two methods, both doing the same thing, but one being secure and one not - and based on your need, you call the appropriate function.

  19. #44
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes...

    both doing the same thing, but one being secure and one not - and based on your need, you call the appropriate function.
    To me, what you are describing is a Strategy, you would pass the required strategy based on the action being public or private. Using this approach removes the decision making away from the class that represents the action in question, as I see it.

  20. #45
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But what if I have dynamic menus - say through installed extra classes (plugins)? Where would you register their menu behavior and display level?
    I have developed a UI where you can move a node in the tree up and down, enabled/disable a node, etc via the user interface; It takes care of the database side of things which you don't see.

    As for plugins, what is your definition of a plugin though? The definition is different for everyone, and the term is very much loose. To give your newly attached plugins behaviour, you could I suppose assign them to groups, thus users have access to them on the per group level?

    Or were you thinking of something else, in terms of behaviour? For more complex applications, by my point of view, a plugin can have other, child plugins as well, with each plugin having it's own behaviour; By that I mean business logic...

    Is that what you are referring to?

  21. #46
    SitePoint Enthusiast
    Join Date
    Jan 2006
    Location
    Amsterdam
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Is that what you are referring to?
    I would refer to a plugin as to a class which gets dynamically included by a controller. The next question would be - how do other plugins know about the fact that they could link to this one and if they do so, when should they display a link where? (I don't know, but maybe I have to take a totally different aproach?)
    It would be great to see examples on how you actually implement the navigation and the inevitable access control.

  22. #47
    SitePoint Enthusiast
    Join Date
    Jan 2006
    Location
    Amsterdam
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I would suggest you do not treat the menu as a menu, but treat it as just another "thing"
    Thats what I am trying I only don't know where to put the navigation (pure navigational data generation) in say the MVC design. It doesn't make sense to me to have it be the View since its not about how it looks but where the navigation data come from. The Model on the other hand seems to be too general, or the other way, the navigation too specific to be a part of the model. The controller as the third one shouldn't really do anything else but handling requests so where would it go?
    A great book talks about this : "Professional PhP5" - in the chapter "Event-Driven Programming" they touch upon the concept of different "Functions" being run under a secure environment or not.
    I'll definitely try to get this book!! Thanks for the tip!

    Nikolai

  23. #48
    SitePoint Zealot
    Join Date
    Aug 2005
    Location
    South Africa
    Posts
    185
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In my opinion, one could use a plugin Registry, or even create a plugin Composite, that gets rendered by a view helper in your view.

    --
    lv

    EDIT: To be true to the thread, I have been using FrontControllers for the last few projects.


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
  •