Using a template engine with a front controller
Moderator: General Moderators
Using a template engine with a front controller
I am building a front controller right now that I plan on using for several applications. I really don't know where to start. Right now I am using smarty for templates. Any advice on building a front controller w/a template engine and perhaps some example code?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
The Front Controller and various Template patterns are totally unrelated and probably not come into contact with each other. A Front Controller is just a front end router, even in MVC the Controller part would not be the Front Controller, but an Action Controller dispatched by the Front Controller.
For templating I creating your Views so that you are able to mix PHP templates with what ever template engine you choose.
For templating I creating your Views so that you are able to mix PHP templates with what ever template engine you choose.
(#10850)
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
Whacky... I really can't follow this yet (seeing as I am still trying to remember what an MVC is - Model/View/Controller or something or other). Anyhow, if I understand this correctly, a page controller handles the part of the processing that gets/sets data and prepares it for display. I am most certainly wrong on this topic, but I like the sound of the keys clicking, so I'll continue...
I have recently built a few sites like this, where there is a general object that gets/sets data, prepares it for display, then returns it to the script. I then take that data and pump it throught the TemplateLite template engine and, Viola!, I have a page displayed. It is really neat and fairly easy to do (as long as you are totally ignorant and haven't learned the MVC thing yet).
I have recently built a few sites like this, where there is a general object that gets/sets data, prepares it for display, then returns it to the script. I then take that data and pump it throught the TemplateLite template engine and, Viola!, I have a page displayed. It is really neat and fairly easy to do (as long as you are totally ignorant and haven't learned the MVC thing yet).
- daedalus__
- DevNet Resident
- Posts: 1925
- Joined: Thu Feb 09, 2006 4:52 pm
- daedalus__
- DevNet Resident
- Posts: 1925
- Joined: Thu Feb 09, 2006 4:52 pm
Daedalus thought he should make a separate post about this...
I have a cruddy class that handles stuff and I have a front controller in it. Now, the front controller calls this other controller which I have not yet named, but basically what it does is decide what action the script should take when it encounters form data...
is that what you meant?
(sorry if im unclear)
I have a cruddy class that handles stuff and I have a front controller in it. Now, the front controller calls this other controller which I have not yet named, but basically what it does is decide what action the script should take when it encounters form data...
is that what you meant?
(sorry if im unclear)
Your front controller is the page that tells which modules (include files) should be loaded. The page that loads would then be your control/view page for that module. This is how I would do it using native templating....
index.php (your Front Controller)
header.php
footer.php
news.php (your Control/View)
news.tpl.php (your template which i consider part of View)
news.cls.php (your class which I consider pat of the Model)
The following page is requested: "index.php?module=news"
* your index page loads your header page
* your index page sees that you want to view the news so it loads news.php
* news.php will create an instance of your news class (news.cls.php) so now you have an object to work with
* news.php will call the method to grab all the news from your database and stores it in an array to use later
* news.php will load your template page (news.tpl.php)
* news.tpl.php will display your dhtml and then loop through your news array into the html format you want
* your index page then loads your footer page
Hope that makes a little sense.
index.php (your Front Controller)
header.php
footer.php
news.php (your Control/View)
news.tpl.php (your template which i consider part of View)
news.cls.php (your class which I consider pat of the Model)
The following page is requested: "index.php?module=news"
* your index page loads your header page
* your index page sees that you want to view the news so it loads news.php
* news.php will create an instance of your news class (news.cls.php) so now you have an object to work with
* news.php will call the method to grab all the news from your database and stores it in an array to use later
* news.php will load your template page (news.tpl.php)
* news.tpl.php will display your dhtml and then loop through your news array into the html format you want
* your index page then loads your footer page
Hope that makes a little sense.
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
My front controllers are impressively basic. I include an autoload function which isn't even really part of the front controller but I just put it in the same file. The front controller itself is purely looking at what page we're on, if it's valid, if a page controller exists to run the page. If everything's ok, the page controller is loaded and the front controller has no purpose from hereon in, if something's wrong a 404 page (On which I usually put a big funky "Ooops" sign) is sent instead.
The page controller gets the model(s) that are needed, deals with any user input to affect exactly what needs to be done with the model and passes the model to the view (also loaded into the controller (via include()). The view then contains just basic template logic to display that data.
Hmm... so basically the front controller just loads the pages.
The page controller gets the model(s) that are needed, deals with any user input to affect exactly what needs to be done with the model and passes the model to the view (also loaded into the controller (via include()). The view then contains just basic template logic to display that data.
Hmm... so basically the front controller just loads the pages.
OK... so basically the front controller just loads any config info and prelogic and then loads the page controller... so the page controller would be what alvinphp is talking about as the news.php page right? And this page would contain all logic specific to that page and pass the model to the view... right?
Does anybody have any examples? (I have arborint's to look at, but I was looking for another perspective too)
Does anybody have any examples? (I have arborint's to look at, but I was looking for another perspective too)
A controller in it's simplest form.. (Technically a Front Controller is ala Apache/IIS.. a Page Controller is what we make in PHP.)
so the various components of the site all come together through index.php?action=whatever
Code: Select all
//include config file.
include_once 'includes/config/config.inc.php';
//which logic to kick in?
$action = (!empty($_GET['action']) ? $_GET['action'] : '');
switch ($action) {
case 'login':
$controller = 'login';
break;
case 'register':
$controller = 'register';
break;
default:
$controller = 'welcome';
}
//include it
include 'includes/controllers/' . $controller . '.inc.php';- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I think the webserver as Front Controller is misleading. What you showed is a Front Controller. We make them in PHP. A Page Controller would always "load" the same controller and only select the method to run. It is in the Page Controller case that the web server is sort of a Front Controller. But it is not actually a Front Controller because it does not centralize any other logic and only dispatch.Jenk wrote:(Technically a Front Controller is ala Apache/IIS.. a Page Controller is what we make in PHP.)
(#10850)
From martinfowler.com:
To me, that sounds like a description of HTTP - all request handling consolidated and channelled via a single handler being what does it for me, because we just simply serve pages/output with PHP.. Apache/IIS/etc does all the http request handling for us.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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Partly ... it is in the "can carry out common behavior, which can be modified at runtime with decorators" where a webserver becomes not a Front Controller. And I agree in a general way that webservers can do the Front Controller's job. But the sense I get (and I could be completely wrong) is that these patterns are not isolated design concepts, but are distilled out of best practices.Jenk wrote:To me, that sounds like a description of HTTP - all request handling consolidated and channelled via a single handler being what does it for me, because we just simply serve pages/output with PHP.. Apache/IIS/etc does all the http request handling for us.
So the Page Controller pattern naturallly encapsulates the "page" concept into an controller object, but then the problem sometimes crops up that you have a lot of duplicate code and that duplicate code in the Page Controllers is diverging slightly due to the usual demands on programmers. The cruft builds up and the code becomes harder to maintain. So in steps the Front Controller to have a place to dispatch, but also to centralize all that common code. So they grow out of necessity and are more code reorginizations than different functionality.
(#10850)
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
If you have your directory layout structured in a uniform fashion something as simple as file_exists('./pages/'.$page.'.php'); will work, although I tend to use the database to list the pages which are available because I can "flag" them as active or inactive pretty easily, and it makes it easier to set permissions for each page this way.The Ninja Space Goat wrote:How would I test to see if a page exists within a certain directory?
In a really simple site/app with only a few pages I'd just make an array in the front controller itself and list the pages in there... then you can just use in_array().