[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