NYCPHP Meetup

[Nate Abele]

Most of the new features I've added to CakePHP have been extracted  
from Real Applications(tm).  It's also flexible enough to allow you  
to modify or replace the framework's functionality at pretty much any  
point in the process.  The only reason you'd ever want to fork a  
framework project is if it is too inflexible, which Cake is not.

The entire point of having a framework like PHP is so that you  
*don't* have to write your applications from scratch every time.  Not  
only that, but half of the brain-work that goes in to designing your  
application is taken out of the equation, because Cake provides you  
with the best (for most web applications) design patterns from the  
very beginning.

> Date: Fri, 17 Nov 2006 19:55:25 -0500
> From: Paul Houle <paul at devonianfarm.com>
> Subject: [nycphp-talk] microframeworks
> To: NYPHP Talk <talk at lists.nyphp.org>
> Message-ID: <455E59FD.7070502 at devonianfarm.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>     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.
>