The front controller is an odd duck when used with php design, merely for the fact that apache in itself is pretty much a front controller, so it always seems weird to me to duplicate apache.
But when modularizing phpFanfiction I ran into a big problem of how to organize stuff so modules could be pretty much drop and go. So after several different designs and discussions it all came back to the same thing... A front controller.
I decided to go the pathinfo route (yeah fun) because it just makes nicer urls, well, kind of
In the end the format is going to be index[.php]/modulename/actionname/any/additional/vars
the index.php can be shortened to index if you have a custom error handler that redirects to index.php, or you use multiviews, rewrite rules, or forcetype in apache. I spent a whole day playing around with all the ways to do url rewriting. That was much fun.
It made me lament the fact that the apache2 (and posibly IIS) sapi for php is so behind. I'd really love to have a way to plug into the urls to do some of that parsing automagically.
Anyway, I read the php mailing lists and I'm just cringing about the stuff rasmus is talking about adding...the automatic get/post filtering.
Now a filtering extension would be great. I'd give my left arm for some easy to use data filtering instructions. It's annoying as hell to deal with it all the time. I'd also give my right arm for an automatic way to "undo" magic_quotes_* (ahh the horror) and register_globals (scares me way too much) in my scripts. But making an ini function to automatically force some filter on all text is just going to make my poor applications have to do even more "ini fixing"
I don't think there's any better word for it than ini fixing... undoing all the crap that silly people do with their ini so the application has a basic environment to run in.
I'm also a bit leery of PDO. If they'd get the basic query - I don't always need to bind variables in and it's annoying to do prepared statements all the time, and if they got the iteration stuff working for results, I'll be a happy camper. I haven't played with a lot since the beginning though, it was crashy/buggy and incomplete and I needed something that worked so I'll hold my breath on how it all pans out.
So I'm to the point where I'm working on actually creating the modules, which really isn't too bad. The biggest thing right now is creating a usable system without any modules installed, because of the fact that there has to be SOME kind of basic authentication.
I ran the access list style route for authorization, but authentication I wanted to leave up to whatever user system the user wanted to install. But then you have the problem of the administration area.
So I ran into the fact that I'd HAVE to install a user and admin module by default...but I COULD allow them to be overwritable. That is you could install a different module with the same functionality instead. So I suppose that's the route I'll go, even though it makes me less than happy.
And I'm still working on setting up extension hooks for the modules. I have the module hooks set up - after all the module actually controls all the action, and you can set pre and post hooks for the whole site - at the moment I can't imagine anything ELSE you'd need. But allowing decent hooks for the modules is another story. The pre and post hook stuff can be set up, so extensions can put them in for the entire module, but really I ought to set up action hooks as well, which could get ugly. Still not sure exactly how that's going to work.
And finally I'm running into the problem of drop and go. I'd love to make the modules all drop and go. To install them, throw them in the modules directory, to uninstall them, delete them. Well that's real great in theory but in real life you run into a two big problems. First of all, pretty much every module is going to need some kind of installation script - because most store data in a database, and most should have an uninstall script to get rid of any stuff hanging around. Then there's the problem of settings. The ideal solution would be to have a config.ini file for each extension which the user could then edit, but on annoying hosts that block writing to files and having to chmod them 777 to make them writeable..that could get annoying as well. So I'm still wavering on that. Plus the problem of activating, deactivating the modules....
Technically I suppose I could always add in a "download" feature for all "can't write file" isps. So the user would edit the config file, download it and then have to ftp/scp it into place. And I could always set up a runOnce feature for modules...that would create the database tables automagically/install the script the first time the module is called. The problem then would be uninstall couldn't be just delete the file....unless a delete script was copied into a portion of the database..... Hmmm, that's an idea.
See, sometimes I just need to talk to myself to get stuff working. Now if I can just talk myself around the admin/user problem so I could set up the application without ANY preinstalled modules I'd be a doggone happy camper.
Although technically if I make the modules automagically self installing.... dang, I'd still have to write the update and configuration features. Unless I make THEM seperate modules as well. So the default use for the site is drop and go modules but create a module module (yeah yeah, stop laughing) that allows update checking, configuration management, activation/deactivation of modules, et al.
Maybe that's the way I should go.
Biggest problem then is what to make the default page for the site...suppose I'll write up a page that shows much like the apache start page :)
I wanted to package the product in a couple of different ways then. A method that uses single download modules...so you download the framework module and work from there, and then site packages, like a full package with everything, and a support site package with forums/bugtrack/wiki/etc. combination. The Holy Grail would even allow webdav/ftp/scp automatic updating. Ahh but that's my imagination getting the best of me.
I suppose now I'll move on to other things...
I'm extremely pleased with the way my templating stuff turned out. I created a very simple template system that assumes basic php file based templates, but can use streams to do compiled templates, template caching, and even db based templates. That was pretty fun to implement. Also the widget and format system turned out nice. Widgets are created by the program and then locked, allowing the template to only change design features (think autofilling tables, forms, lists). Any formatting functions can simply extend out from the format class and be anything under the sun. They just have to accept a string and output a string....
Well, I suppose that's enough blabbering on phpFanfiction.... I've been calling it pff now that it's a little more multifunction. Don't know if I'll go so far as to completely change the name or not. We'll see.