NYCPHP Meetup

[Jon Baer]

My whole take on frameworks (and languages in general) is the  
debugging process.  In a web application if something does not look  
right or function correctly am I going to know exactly *where* to  
look for the problem?  In an MVC ideal its pretty simple (even if you  
look at in GUI terms) ... its ridiculous to spend an entire day  
tracking down where $_variable is and what it does.    They were  
doing that 10 years ago in C and C++.  I like smarter languages and  
smarter frameworks.  If you write one or two lines of code +  
everything is figured out for you, its pretty powerful stuff to take  
for granted.

- Jon

On Nov 18, 2006, at 6:40 PM, Nate Abele wrote:

> 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.
>>
>
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
>
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php