NYCPHP Meetup

NYPHP.org

[nycphp-talk] microframeworks

Paul Houle paul at devonianfarm.com
Fri Nov 17 19:55:25 EST 2006


    Last week somebody asked what framework he should be use for a 
project.  People brought up the usual suspects,  such as CakePHP,  
Symfony,  Andromeda and the Zend Framework.  Yet,  I get the feeling 
that more people are talking about frameworks rather than using them;  
the talk-to-action ratio depends on the framework,  but I think 
frameworks haven't yet "crossed the chasm" to mass adoption.

    The other day I had to get an application started in a hurry.  It's 
doing something useful at < 700 lines,  but I'm considering options that 
could grow it out to about 10 times that.  It depends on a "core 
library" that's < 500 lines.  This library deals with common issues in 
string handling,  parameter handling,  and HTML form generation.

    About 10% of the application,  or 70 lines,  is a microframework 
that's loosely built on Struts.  About 20 of those lines are in 2 
functions which would be generally useful for microframeworks (such as 
file_exists_in_include_path()).  Like Struts,  the microframework 
chooses an "action" based on form parameters:  the action then chooses a 
"view" -- a "view" is basically a template that a designer can edit 
which can be supplemented by an optional "query" which pulls stuff out 
of the database.  Like Ruby-on-Rails,  the microframework uses 
convention instead of configuration:  the dispatcher computes an "action 
name" based on query parameters,  and uses that to compute a 
filename...  It checks that the file exists and executes it with the 
"require method".

    The microframework uses no object-oriented techniques.  That's not 
because I have any antipathy to OO,  but because I didn't need it,  and 
I like writing my actions,  queries,  and views in a style that "feels 
like PHP".

    Yes, my microframework is nowhere near as powerful as CakePHP or 
Symfony.  Yet,  it's more flexible,  because I can codesign it with my 
application.  Because it's so simple,  I can easily adapt it to do what 
I want.  If I decide I really hate it,  I can write a new one in an 
hour.  I'm an expert on it,  because I developed it,  and I wouldn't 
have to take on the technical,  social and emotional burdens of 
"forking" an open-source codebase if I wanted to make a change in direction.

    I'm moving towards a vision of web app architecture where we move 
towards shared vocabulary and standardized interfaces.  Rather than 
working with a "comprehensive framework" that does everything,  I'd like 
to have a "framework construction set" that contains a number of 
elements that I can take or leave.








More information about the talk mailing list