So would I be feeding the stuff in bold to index.php to the controller code in there, or would I be feeding it to articles.php to the controller in there?
In my system eveything gets sent through index.php. This has nothing to do with using a front controller though. Your directories would be virtual and would probably just map to nested articles or folders system if implemented. MVC is usually touted as an application development framework, which is why you haven't seen "smooth" URL's. That URL is more likely found in a front end of a CMS or content delivery engine.
You can still use MVC (which I do) as the framework for such an engine.
If passing to index.php, then I can see that becoming one monstrously big controller file, if, say, this were a website that offered up a lot of features. And if broke out into separate controller files, then I don't see the point of using a controller when you could just parse the incoming URL and go to town operating on the application logic, right away. If there are separation of concerns, then great, even without an official MVC platform, one could just use other techniques to separate their SQL from their HTML from their application logic.
It would become a large index.php if you kept index.php hardcoded or static.
Code: Select all
$page = $_GET['page'];
switch($page){
case 'about-us':
{
// TODO: Instantiate model and/or view
echo 'Create your view or template for about-us';
break;
}
case 'insurance-calculator':
{
// TODO: Instantiate model and/or view
echo 'Create your view or template for calculator';
break;
}
case 'index':
default:
{
// TODO: Instantiate model and/or view
echo 'Create your view or template for default landing page';
break;
}
}
Although some might argue this is not technically a front controller I see the concept as being very similar -- in that each CASE is a hardcoded action controller. What a front controller does do, is remove that hardcoded dependency by making each CASE a "module" or "action controller".
You can see the benefits to having a single index.php as athe application entry point, right? But you also see the
switch growing to massive size. What the front controller does is something like:
Code: Select all
$page = $_GET['page'];
$html = execute("controllers/$page.php", $_REQUEST);
// TODO: Apply any filters to resulting HTML -- such as hyperlinking URL's or hilighting key words
echo $html;
Where execute might look something like:
Code: Select all
function execute($controller, $request)
{
include($controller);
$controller_name = basename($controller, '.php');
// TODO: Fetch $action from $_REQUEST
$action = $_REQUEST['action'];
$controller_object = new $controller_name();
return $controller_object->$action($request);
}
And your action controllers might look like:
Code: Select all
class MyController{
function doSomething($request)
{
// TODO: Create model and view and return results
$smarty = new Smarty(); // Or CCAPS
return $msarty->execute(); // Or whatever the rendering function is called
}
}
Now you could use a front controller with a URI like:
index.php?ctrl=MyController&action=doSomethingCode: Select all
$ctrl = $_GET['ctrl']; // Get the controller name
$html = execute("controllers/$ctrl.php", $_REQUEST);
// TODO: Apply any filters to resulting HTML -- such as hyperlinking URL's or hilighting key words
echo $html;
This is a very crude example but should demonstrate the basics in how a front controller prevents your index.php from growing into something nasty. Action controllers are simply PHP scripts/functions/classes/whatever that have their context set for them by a front controller, saving you from repeating your self.
So, for me, my controller isn't named a controller, but it does the same thing.
Probably the best thing patterns have done for me, is give me a common language to use. If you have been programming for any number of years, most patterns probably make sense and are even solutions you've applied in the past under your own monikers. Problem is what you call a module loader, someone else might call a kernel and someone else might refer to it as an engine, etc.
All these names are great but when I first enter a codebase I have no idea what any of those terms mean and while documentation helps, wouldn't it be best if the code described itself and allowed you to focus your commenting skills on code that really needed it?
Piece of cake. No tremendous learning curve
I could have a developer up to speed within a few days on my system, which is a fraction of the time I have experienced with every project I have ever worked on.
And it runs much faster than any MVC framework I've seen because it has less layers of goo to get through
While my system has many layers I would challenge any project to a benchmarking contest of equal size. In my experience, the extra layers serve to modularize your application, meaning only components which need executing actually get parsed. I estimate about a 2% parsing overhead of code that actually doesn't get executed, I would put most other applications I've worked on at 20-40%.
Zend has a lot of complexity. Even simple components like the request object are massive. Not all MVC frameworks are created equal.
Reading my source is very clean
Everyone thinks their source is really clean, that is what my last employer promised me too and it took 3 months to learn 50K lines in and out. You know what clean means to me?
1. Small, simple well named functions. Are any of your functions over 50 SLOC (not physical)? Not clean anymore.
2. Does your code ever use more than 2 levels of nesting? Whether it's an nested IF or WHILE? More than two equals code smell.
3. Are your variables ever acronymized? $arr $cnt $res? I consider that a code smell.
4. Do your comments consume more than 5% of your physical lines of code? Yes? That I consider a code smell.
5. Do any of your functions, classes, modules, files or folders has similar names? If you have more than one directory named 'core' that is a code smell.
6. Do you have *any* HTML anywhere outside of your templates? Even a simple boldify. I consider that a code smell.
7. Do you have anywhere, more than a dozen files in any one directory? I consider that a code smell.
8. Do you have any code duplication more than 4-5 lines? I consider that a code smell.
I could go on all day but I won't cause you get the point. Everyone has different standards and ideas as to what constitutes clean code. My biggest gripe with code is seeing response code in the index.php or template code in the controller or validation code in the data access layer, etc. My applications are extremely modular and I expect things to be where they make sense to me. The minute they don't I have to start learning a system.
I mean, I've done the MVC thing for a bit. Worked with Zend. Got my secret decoder ring and a T shirt. Went woo hoo. Learned from it. Saw it slow down dev time and running code time. Didn't see the point. Moved on to my own thing, just more polished from there on out because I learned from the MVC.
Where is my secret decoder ring?
So you admit you learned from MVC and polished your practice? What makes you think the learning has stopped? MVC will take a long time to fully understand, and in fact I'm not sure you ever stop learning. There are so many questions of what goes where and why you have to answer when you really think about it, and to complcate matters, sometimes code makes sense in the controller when other times it makes sense in the model. Depends on your particular architecture.
I've also seen him say, and I don't have the quote right in front of me, that when he wants to speed something up, he tries to rewrite it better in PHP. But when that fails to deliver significant results, he writes it in C and throws it into PHP as an extension. That was another interesting view, as well, for me.
Writing a function in C woudl certainly speed things up, yes...what does that have to do with MVC?
