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.
begin:vcard
fn:Kenneth Downs
n:Downs;Kenneth
adr;dom:;;347 Main Street;East Setauket;NY;11733
email;internet:[EMAIL PROTECTED]
tel;work:631-689-7200
tel;fax:631-689-0527
tel;cell:631-379-0010
x-mozilla-html:FALSE
url:http://www.secdat.com
version:2.1
end:vcard
_______________________________________________
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
