Just to add to this disscussion:
The reason I asked this question is because I am beginning to wonder if I have over-complicated my front controller (copying Zend, etc). Having read countless articles on design patterns and a few books to boot I sometimes feel that some developers are over zealous in implementing a design pattern exactly as stipulated in a book, etc.
For example, the front controller clearly derived from traditional event driven desktop style applications where a message loop is absolutely required. However I'm not sure if the exact implementation of a front controller is *really* nessecary in the world of web development.
I mean, Apache and mod_rewrite already do something of what a front controller does but most importantly, a message pump isn't really needed because of the very nature of the Web and it's REQUEST/RESPONSE model.
It doesn't often make sense (at least I have yet to witness something practical) to have a front controller implemented with the ability to handle multiple requests in a single HTTP request - the two simply don't jive. I considered this while implementing my 100th version but figured to go with in for the sake of flexibility. But I haven't needed it.
The example I gave d11 above, demonstrates a possible use in that one could use the message pump to first handle actions (Creating a user, etc) and then continuing as normal with display the FORM or thankyou note (without a refresh - saving bandwidth). This is I think why most developer implement the front controller with such funcitonality but as d11 noted, the redirect is nessecary after a CRUD operation anwyays otherwise
F5 for your user could cause some troubles.
So, again, I ask, does anyone know of an actual 'practical' purpose to have multiple actions handled per HTTP request (despite IMHO going against the very grain of the technology).???
I'm thinking I might drop my loop implementation for a simple straightforward single action handler front controller.
Cheers
