Page 1 of 1
feyd or arborint
Posted: Sat Mar 17, 2007 8:01 pm
by alex.barylski
feyd, because is the master of searching and finding topics on these forums...and because you simply have the most exposure to the content on these forums.
arborint, because if memeory serves, you were the author...
I can't for hell or high water find the basic trivial implementation of a front controller arborint demonstrated a while back
Can someone find that for me?

Posted: Sat Mar 17, 2007 8:19 pm
by John Cartwright
"or Jcart"
I believe this is what you are looking for is
http://ap3.sourceforge.net/
Posted: Sat Mar 17, 2007 9:13 pm
by alex.barylski
Hmmm....I guess thats what I was asking for, but it's not what I was expecting...
I really just want to see a minimal single class front controller implementation, to compare to my own...Zend (while flexible) is way over kill for my own needs. I enjoy some abstraction, but I find Zend is a little to zealous.
Off the top of my head, here is the API of my current:
Code: Select all
class Front{
setControllerPath($path);
setControllerArgs($name, $object);
startMain($ctrl, $action);
_loadController();
_execAction();
}
I don't need any router/mapper abstractions, I can handle those directly via startMain() if needed...so I'm sure you can see where i'm going with this...KISS...literally...
Comments, suggestions, feedback?
Posted: Sun Mar 18, 2007 1:05 am
by Christopher
Posted: Sun Mar 18, 2007 7:09 am
by alex.barylski
Cool, thanks man
My API is slightly more verbose, but it seems we basically share a common idea of what a simplisitic (not overly abstracted) front controller would do.
One question though, a quick glance at your code but it appears you are missing a critical component for a powerful front controller, that is of any kind of dispatch mechanism???
As I understand it, Zend implements something of a message queue (analogous to Windows message queue) as well as a message pump (for or while loop) which repeats until there are no more controller:action pairs to be handled???
Without me requiring to further look at Zend source, is this not an integral part of the front controller or is it implemented as a abstraction or plugin to the system itself? Personally I see it making more sense as a core element of the front controller...
Thoughts?
Posted: Sun Mar 18, 2007 9:31 am
by onion2k
Not a 'who would win in a fight' thread then?
Posted: Sun Mar 18, 2007 9:50 am
by alex.barylski
Posted: Sun Mar 18, 2007 11:09 am
by John Cartwright
Hockey wrote:Cool, thanks man
My API is slightly more verbose, but it seems we basically share a common idea of what a simplisitic (not overly abstracted) front controller would do.
One question though, a quick glance at your code but it appears you are missing a critical component for a powerful front controller, that is of any kind of dispatch mechanism???
As I understand it, Zend implements something of a message queue (analogous to Windows message queue) as well as a message pump (for or while loop) which repeats until there are no more controller:action pairs to be handled???
Without me requiring to further look at Zend source, is this not an integral part of the front controller or is it implemented as a abstraction or plugin to the system itself? Personally I see it making more sense as a core element of the front controller...
Thoughts?
I think a dispatcher is more of an addon to the front controller as it is not neccesary, although definantly a plus.
Posted: Sun Mar 18, 2007 1:04 pm
by alex.barylski
If I understand the purpose behind a disptacher, then under *most* circomstances it would be require...
Do you mind me asking for your own definition or interpretation of a dispatcher in a front controller?
Posted: Tue Mar 20, 2007 6:39 am
by Maugrim_The_Reaper
Do you mind me asking for your own definition or interpretation of a dispatcher in a front controller?
Basically it handles the calling of controllers. You could implement in the Front Controller itself but since the FC is by and large a simple animal the complexity of calling controllers/actions as well as handling dispatch staging (e.g. plugin integration) is better left in a separate class. In a simple implementation you would avoid Routing logic as much as possible so the dispatcher requires no routing classes (which is largely where the ZF complexity is sourced by the way since the rest is pretty standard).