Front controller and application levels (again)
Posted: Thu Mar 22, 2007 9:52 pm
I can see how a front controller would work magic on an application with a single level menu system
Assume that to be the primary menu. 
Instead of using a switch
You could seperate each tab into a action and call a controller named master. The master controller is loaded on every page request and delegates the request onto appropriate action handler.
Now assume that each action is to perform some logic and act something like a page controller.
Assume I have something like this for Master controller:
That last TODO is where I am confusing myself (this is a home-rolled interpretation of model2 MVC - not Zend):
I have managed to wire the Views togather, as the Master view has a member ($_body) which contains the sub-controller viewport. However, this is accomplished by creating View objects inside the Master (either at construction - as required) or inside each controller-action handler, like actionArticles.
I am tempted to try and clean this up(remove some dependencies?) by instead of hard-coding the view creations I simply pass control to a sub-controller (which would act as a page controller, loading appropriate views, handling actions, etc) using a dispatchMessage().
The problem with the latter approach, is the way views are utilized/constructed and then sent to screen. I cannot simply echo the contents of each View and expect the resulting output to be properly organzied.
So I ask, which way is better and why? Obviously, as it stands right now, the latter might now even work (I have to spend some more time thinking).
How do you solve these issues? Using pusedo-code would be best...so it may apply to both my own library and/or Zend...
Please be detailed, as anything you can do to offer insight is appreciated
Cheers
Code: Select all
Dashboard | Articles | Resources | AdminInstead of using a switch
Code: Select all
switch($page){
case 'dash':
case 'articles':
case 'resources':
case 'admin':
}Now assume that each action is to perform some logic and act something like a page controller.
Code: Select all
function actionArticles()
{
// TODO: Are we doing any of the following:
// 1) Create new article
// 2) Update existing
// 3) Search
// 4) Listing
}Now my Master controller is actually derived from a base (ABC) and this master (in ctor) initializes the View (setting tabs to inactive by default). Each Action is then responsible for resetting the view according to it's state. So if Articles is selected, the articles "tab" is made to appear "Active".Note: Creating & Updating both require a seperate actions but don't rely on any GUI so loading of views, etc is redundant.
Assume I have something like this for Master controller:
Code: Select all
class Master{
function Master()
{
// Initialize master View with all tabs disabled by default
}
function actionArticles()
{
// Reset the Master view so that "Articles" tab is now selected
// TODO:
// Fire up "Articles" sub-controller (which loads "Articles" interface)
}
}I have managed to wire the Views togather, as the Master view has a member ($_body) which contains the sub-controller viewport. However, this is accomplished by creating View objects inside the Master (either at construction - as required) or inside each controller-action handler, like actionArticles.
I am tempted to try and clean this up(remove some dependencies?) by instead of hard-coding the view creations I simply pass control to a sub-controller (which would act as a page controller, loading appropriate views, handling actions, etc) using a dispatchMessage().
The problem with the latter approach, is the way views are utilized/constructed and then sent to screen. I cannot simply echo the contents of each View and expect the resulting output to be properly organzied.
So I ask, which way is better and why? Obviously, as it stands right now, the latter might now even work (I have to spend some more time thinking).
How do you solve these issues? Using pusedo-code would be best...so it may apply to both my own library and/or Zend...
Please be detailed, as anything you can do to offer insight is appreciated
Cheers