NYCPHP Meetup

[Jayesh Sheth]

Hello all,

thanks for your great, well-thought-out responses!
I agree with John Andrews (I keep wanting to call him Andrew!) that
there is a lot of advance learning required before getting into a
(heavy) framework. I also agree with Kenneth Downs that people often
write frameworks because they are fun to write (and always because they
are needed). 

When you are coding within the confines of a framework, you are expected
to do common things (database calls / business object usage,
configuration reads, template output) through the framework, and not
outside of it. There are some frameworks which have proven themselves to
be immensely useful, and perhaps indisensable to some. One of these, I
have heard, is Struts for Java. Another one for PHP that looks
beautifully perfect is Seagull (it uses PEAR libraries too). I like
Seagull's approach of building on existing PEAR libraries. This is good
for two reasons. The first is that there is no reinventing the wheel
[example: for form generation and validation (PEAR HTML_QuickForm is
used), and for DB access (PEAR DB is used)]. The second is that PEAR is
emerging as the de-facto standard for object oriented PHP code; by
building on PEAR, Seagull is using proven libraries to make a great
framework. I have not used Seagull, but I have looked at its code and
online docs. And there have been a bunch of (positive) articles about in
the PHP Journal / Magazine space recently.

Having thought about it a bit, I think that when phpBB was initially
released, it was coded by a small group of people, and filled an unmet
need. It grew greatly in popularity over time, but its codebase never
changed. It has some funky things in it that would prevent easy changes;
for example, in some scripts, there is a large switch / case block that
constructs SQL for either MySQL or Postgres or other DBs. It would have
been better to use different DB 'drivers' or classes for each DB type,
and pass an instance of those in at runtime (Strategy pattern: identify
the things that change, break them into their own classes, and using
composition pass them into another object at run time).

Then again, these very thoughts (cool design patterns) fill the heads of
people who write frameworks. And what can happen is that the framework
comes before the software that has to be written. What I mean is that
writing a cool framework becomes a goal in itself, rather than
supporting the end-goal of creating a piece of software that serves a
particular purpose well. 

I think it is really hard to write good software, and it is even harder
to write a good / useful framework. Writing a framework often involves
mind-reading, because a good framework will anticipate the needs of
applications that need to be built on top of it, and support it either
inherently or through easy extension.

There are many applications out there that serve a single purpose, and
do what they do very well (from a functionality point of view). They may
not be coded well, but from the user's perspective, they have cool
features, and work well. Examples in the PHP world are phpBB, Tasks Lite
/ Pro and Gallery. These applications may have chunks of HTML stuffed
into random strings, they may not use many functions, but they provide a
host of features that work, they are updated often, and many millions of
people use them.

I think it is unfortunate that many products that are built
on top of obsessed-over, carefully written frameworks fail to meet the
business needs they originally set out to fulfill. Thought: If at the
end of the
day a product does not serve its end users well, then should it be
considered a failure?

Just my 2 words cents :-)

- Jay