What I’m doing, what seems to be working in my early experiments, is to stop the abstraction. Basically, abstracting the core components - the classes that are loaded by the code the user isn’t supposed to touch, is one thing, but abstracting the code the user is going to be routinely working with is just gross overkill.
There is no router configuration in PNL. Controller load files lie in the map directory at the same location one would expect them to lie in htdocs (the reason they are not in htdocs is PNL uses that directory for caching in the attempt to preclude itself and most all of PHP from the majority of page loads). Every class we load getting to that point except the root starting class is configurable just as in Magento, Cake, Symphony or the like. Once we reach the controller load files we branch to two major possibilities.
First is that the “control load file” is actually a view. It will echo out content and fetch things from models without using (or heavily using) a template library. This is a design choice, but for small pages and projects a legitimate one. MVC still exists here - we’re still using a front controller to reach this view file, but further separation hasn’t occurred.
Second is the load file starts up one of more classes directly like this
$response = new Page($this); // This is the front controller and dispatcher, pretty much all control classes require it as a parameter.
$response->parse();
And the Page class is custom logic for that page that knows what it’s templates and models are without being told by any config files. If you need to change these things, you extend the base class as needed. To abstract with a factory at this juncture is pointless - you end up with binding code at least as, if not more complex than, the code you end up writing here in PHP.
The general flow outside the loader remains the same - parsing the page causes it to load its event(s) onto the event dispatcher in the desired order of execution - loading the queue. Then each is dealt with separately.
I’m taking a middle ground here - I don’t think the overkill of Magento, Cake, Zend, Symphony et al is the answer. I don’t think Death Shadow is anywhere near right either. I’m probably going to be wrong on my first few attempts but my hunch here is that some abstraction is indeed good, all abstraction is bad.
I will note I agree with Deathe on the need to handle parser code with compiled code for maximum speed. Eventually the front controller & router of this framework will be a C++ extension for PHP. The PHP version will remain though as a reference and teaching tool - the C version will be the optimized version.