NYCPHP Meetup

[Kenneth Downs]

Paul Houle wrote:
>     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 buzz on frameworks is the precursor to the uptake.

But PHP does have very successful frameworks, those that are suitable to 
origins as a web platform.  Content management systems came first, and 
Joomla has a healthy community around it.  Those were the first PHP 
frameworks, and their focus is, naturally, tightly coupled with the idea 
of PHP as a dynamic content serving tool.

Now PHP is recognized as a powerful general-purpose server language, and 
so the masses of biz app authors are coming over and the frameworks are 
being born.  There will no doubt be more on the horizon, though IMHO 
Andromeda is the only one you need :)

>     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.  
Ain't it always the way :)  and ten times after that, and ten times 
after that....

When I worked in Manhattan I would often have to cut meeting short by 
saying, "Look, the last thing we need now is more good ideas, how about 
we actually code some of this stuff?"

> 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.
>   
I cannot fault your approach in attacking first the items that are 
important on the first project, I did the same with Andromeda.  Strings, 
parameters and HTML.  Conspicuously absent from the list though is 
rudimentary SQL generalization, have you hit that yet?  Do you have any 
thoughts yet on security?


>     About 10% of the application,  or 70 lines,  is a microframework 
> that's loosely built on Struts. 
This is suspicious.  Why is only 10% of the app in the framework? 

For the sake of framing a debate, lets say that if the framework code is 
< 50% of the app, then the framework itself is less mature than the app.

>  About 20 of those lines are in 2 
> functions which would be generally useful for microframeworks (such as 
> file_exists_in_include_path()). 

Perhaps this should just be called a library at this point?

>  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".
>   

Now I must respectfully but firmly insist that this is not a framework.  
Conventions are a requirement for rigorous development, but they don't 
make a strategy any more than buying a computer makes you a programmer.

The danger of this path is death by success.  Conventions work very well 
for 2-4 people, but beyond that they cannot be maintained through 1-1 
communication, and they begin to break down when expediencies demand 
quick results (remember, going from 2 programmers to 5 means you are 
doing well, so now you have those pesky customers with their 
unreasonable demands). One compromise on top of another and sooner or 
later it all collapses.  You can see this coming when people start 
talking about the "next framework" and how it will redeem us all from 
the failures of the first.  When you've seen this go around twice you 
begin to get suspicious that Godot is not coming.

>     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".
>   
My own experience suggests you are one the right track.  I went through 
the OO mania in the mid 90's and have come out comfortable in leaving OO 
mania to the OO maniacs. 

Consider this: a web transaction is a stateless time-sensitive event.  
By its very nature performance concerns play into every design and 
coding decision.  Any element, such as OO, that adds overhead and 
complexity must prove itself overwhelmingly valuable to gain adoption.  
Since there is nothing that OO does that you cannot do without it, 
better to avoid the false dreams and just stick to writing well-defined 
functions that accept parameters and return values.

>     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. 
Here I will play devil's advocate with two arguments.

One, "it is not as powerful as...." to which I add, "..and therefore not 
as valuable."  Having a small code set is great for maintenance and 
quality, but it is not a goal in itself, it is only a goal if it 
contributes to quality through maintainability.  Having a small body of 
code that does a small body of things is not the goal, by that measure a 
blank page wins.

Andromeda's entire library is less than 10,000 lines.  This very morning 
I finished off the first usable version of our publishing and version 
control system, and the entire thing came in at about 900 lines.  What 
makes the 900 line count attractive is that it is easier to debug and 
enhance 900 lines than 9000.  I do not claim, "look it is small" I 
claim, "Andromeda lets you manage patches and revisions, stamp versions, 
and publish code node-to-node for free".  The 900 line count just means 
it will go stable that much faster.

Second, I will play devil's advocate and say  it is *not* more 
flexible.  There is an illusion of flexibility because your small 
feature set leaves future decisions open, but it cannot free you from 
the inevitable day when you must decide on each item.  As your projects 
roll in and your needs press in, you will decide how to handle multiple 
browsers, security, user features already present in other systems, and 
so on and so on.  Each decision will press all future projects to 
conform to the decision as it was made *at* *that* *time*.  Unless you 
are perfect in your decisions, the larger the framework becomes the more 
of a chokehold it gains on your development shop.  So flexibility is not 
found in a small feature set, we must look elsewhere for a definition.

A truly flexible framework does lots of work for you, lets you override 
it when you think you're smarter, and, very importantly, let's you 
repent of your decisions and change your mind without breaking 
anything.   This is the kind of flexibility that we are after with 
Andromeda, and I like to think we've done it.  Here is an example.  We 
are doing a system for a magazine distributor that has about 40 tables.  
All but 5 of them are maintained with normal screens for which we did 
zero programming, they all came for free.  But there are 5 crucial 
operations that by their nature require custom screens, so we are doing 
5 custom screens loaded with Ajax and lots of alerts, validations and so 
forth.  Andromeda is flexible because it not only allows me easily to 
put up menu items pointing to custom forms, but it also provides me with 
facilities to determine the security of those forms, routines for Ajax 
and HTML generation, and so forth. 


>  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.  

Lots of people have heard of the KISS principle, "Keep it Simple, 
Simon".  But most have not heard of Einstein's variation, "Keep it as 
simple as possible, and *no* *simpler*."  Remember that we said above 
that if simple is better, a blank page wins.  The real genius is in 
accomplishing necessary goals in a simple way.

A framework is a middle ground in the "generalization-specialization" 
problem.  Something like PHP is perfectly generalized, it can do 
anything in potential but out of the box cannot actually do anything 
practical.  A finished program on the other hand is perfectly 
specialized, it can do one thing well but cannot do any other thing.  A 
framework is supposed to be in the middle.  A CMS framework specializes 
in CMS systems, but still has enough generalization in it to allow for 
all of the variations that are necessary.  A business framework like 
Andromeda specializes in eliminating labor from the task of drafting, 
revising, delivering and documenting complex business apps.  But it 
still has enough generalization to allow for other variations.


> 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.
>   

Why not just talk to the developer? Why fork?  Why not make code 
contributions to a framework?  Nate of CakePHP is on this list, and so 
am I.   If you use Andromeda I benefit, so I want you to use it.  The 
law of averages says that anything you want is likely to be desirable to 
other programmers, so I want to know what you need and get it in there. 

I wish you luck and I thank you for bringing these thoughts to the list, 
I'm looking forward to more fruitful discussion.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ken.vcf
Type: text/x-vcard
Size: 261 bytes
Desc: not available
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20061118/bd0989d0/attachment.vcf>