php-general Digest 10 Dec 2010 13:27:02 -0000 Issue 7079
Topics (messages 309938 through 309948):
PHP 5.2.15 Released!
309938 by: Ilia Alshanetsky
Re: ORM doctrine
309939 by: Larry Garfield
309940 by: Daevid Vincent
309941 by: Tommy Pham
309942 by: Paul M Foster
309943 by: Philip Thompson
309945 by: Tommy Pham
A general discussion of libraries and frameworks
309944 by: Adam Richardson
309946 by: Tommy Pham
309947 by: Richard Quadling
309948 by: Bob McConnell
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
The PHP development team would like to announce the immediate
availability of PHP 5.2.15. This release marks the end of support for
PHP 5.2. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3.
This release focuses on improving the security and stability of the
PHP 5.2.x branch with a small number, of predominatly security fixes.
Security Enhancements and Fixes in PHP 5.2.15:
Fixed extract() to do not overwrite $GLOBALS and $this when using
EXTR_OVERWRITE.
Fixed crash in zip extract method (possible CWE-170).
Fixed a possible double free in imap extension.
Fixed possible flaw in open_basedir (CVE-2010-3436).
Fixed NULL pointer dereference in ZipArchive::getArchiveComment.
(CVE-2010-3709).
Fixed bug #52929 (Segfault in filter_var with FILTER_VALIDATE_EMAIL
with large amount of data).
Key enhancements in PHP 5.2.15 include:
Fixed bug #47643 (array_diff() takes over 3000 times longer than php 5.2.4).
Fixed bug #44248 (RFC2616 transgression while HTTPS request through
proxy with SoapClient object).
For a full list of changes in PHP 5.2.15, see the ChangeLog on
<http://php.net/ChangeLog-5.php#5.2.15>. For source downloads please
visit our downloads page on <http://php.net/downloads.php>,
Windows binaries can be found on <http://windows.php.net/download/>.
Ilia Alshanetsky
5.2 Release Master
--- End Message ---
--- Begin Message ---
On Thursday, December 09, 2010 12:45:38 pm David Harkness wrote:
> On Wed, Dec 8, 2010 at 11:11 PM, Daevid Vincent <dae...@daevid.com> wrote:
> > Avoid these ORM things like the plague! . . . Not to
> > mention all that fancy "ORM" doesn't come without a price. It costs in
> > terms
> > of speed, as well as training.
>
> If you value CPU time over developer time, by all means avoid ORM
> frameworks (and *all* frameworks). The point of a common framework is to
> trade a small bit of performance for a large amount of developer time. If
> you will only use the framework once, the payoff will be much less. The
> goal is to choose frameworks that you can leverage again and again.
>
> As for training, you will be able to hire another developer that knows
> Doctrine. It will be impossible to find a developer *anywhere* that
> understands your home-grown framework without training. Nor will you get
> help with bugs in your framework or be able to discuss better ways to use
> it on forums.
>
> That being said, there are times when it's better to write your own code. I
> will do this if the options out there don't suit my needs or if they seem
> under-supported. For example, while we use PHPUnit and Zend MVC in our
> apps, I wrote my own TestCase subclasses instead of using Zend's. I had to
> write documentation for the other developers, and I must maintain it as
> needs change. It was not a decision I took lightly.
>
> David
ORMs are fundamentally fighting the wrong battle. They have their use, but in
general they are architecturally not something you want to build your entire
system on.
See:
http://www.garfieldtech.com/blog/orm-vs-query-builders
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
--Larry Garfield
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> > If you value CPU time over developer time, by all means avoid ORM
> > frameworks (and *all* frameworks). The point of a common
> framework is to
> > trade a small bit of performance for a large amount of
> developer time. If
> > you will only use the framework once, the payoff will be
> much less. The
> > goal is to choose frameworks that you can leverage again and again.
I disagree. If you use a framework, then you're stuck with it. Bugs and all
(and trust me there are bugs and limitations you WILL run into). If it's
your code, you can fix it. If it's someone elses' you have to submit a bug
report and HOPE they fix it. If they don't you are now forced with either
patching every new release or working around it.
> > As for training, you will be able to hire another developer
> that knows Doctrine.
Doubtful. It's hard enough to find skilled PHP developers as it is.
Everyone and their mother THINKS they're a LAMP guy. Test them. You quikly
find out that buzzwords on a paper resume are not the same as a real
developer.
> > It will be impossible to find a developer *anywhere* that
> > understands your home-grown framework without training.
That's just it. DO NOT make a "framework". Make some helper routines for
common tasks like sql_query(), sql_insert(), sql_update(),
sql_select_box(), etc. and stick to the "basics".
Frameworks are a waste of time and energy -- homegrown or off-the-shelf.
They try to be all things to all people and turn into a "jack of trades,
master of none". They're bloated and cumbersome and force you to wedge
square pegs into round holes all the time.
> > Nor will you get
> > help with bugs in your framework or be able to discuss
> > better ways to use it on forums.
That's what your employees, team-mates, customers, testers, etc. are for...
If you're making "JoeBlowsRinkyDink.com" then go for the framework if you
want to play with it for the massochistic experience and to learn your
lesson the hard way. But don't use it for paying customers and certainly
don't use it in an enterprise level -- it will be the death nail to your
project ultimately.
Use PHP the way God intended it to be used.
I leave you with this old Poll I posted:
http://www.rapidpoll.net/show.aspx?id=8opnt1e
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Larry Garfield [mailto:la...@garfieldtech.com]
> Sent: Thursday, December 09, 2010 5:35 PM
> To: php-gene...@lists.php.net
> Subject: Re: [PHP] ORM doctrine
>
> On Thursday, December 09, 2010 12:45:38 pm David Harkness wrote:
> > On Wed, Dec 8, 2010 at 11:11 PM, Daevid Vincent <dae...@daevid.com>
> wrote:
> > > Avoid these ORM things like the plague! . . . Not to mention all
> > > that fancy "ORM" doesn't come without a price. It costs in terms of
> > > speed, as well as training.
> >
> > If you value CPU time over developer time, by all means avoid ORM
> > frameworks (and *all* frameworks). The point of a common framework is
> > to trade a small bit of performance for a large amount of developer
> > time. If you will only use the framework once, the payoff will be much
> > less. The goal is to choose frameworks that you can leverage again and
> again.
> >
> > As for training, you will be able to hire another developer that knows
> > Doctrine. It will be impossible to find a developer *anywhere* that
> > understands your home-grown framework without training. Nor will you
> > get help with bugs in your framework or be able to discuss better ways
> > to use it on forums.
> >
> > That being said, there are times when it's better to write your own
> > code. I will do this if the options out there don't suit my needs or
> > if they seem under-supported. For example, while we use PHPUnit and
> > Zend MVC in our apps, I wrote my own TestCase subclasses instead of
> > using Zend's. I had to write documentation for the other developers,
> > and I must maintain it as needs change. It was not a decision I took
lightly.
> >
> > David
>
> ORMs are fundamentally fighting the wrong battle. They have their use,
but
> in general they are architecturally not something you want to build your
> entire system on.
>
> See:
> http://www.garfieldtech.com/blog/orm-vs-query-builders
> http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Scie
> nce.aspx
>
> --Larry Garfield
>
When I did some projects in Java+Hibernate a while back, it was very helpful
when dealing with the basics at first. As for developer time, it didn't
improve much as it took more time for me to understand Hibernate then just
doing the standard DB abstraction + business object. Also, I later came to
realize that setting up the class model for Hibernate to work is about the
same time spent just doing abstraction + BO. Result? More time loss due to
learning Hibernate and decrease performance due Hibernate's use of
reflection. However, I still am interested in ORM to see if there's been
improvement. Here's a classic case example:
create table `category` (
`id` int not null auto_increment primary key,
`parent_id` int not null default 0,
`name` varchar(75) not null,
Key `parent_id` (`parent_id`));
class Category {
private $id; // int
private $parentId; // int
private $name; // string
private $subcategories; // array
// class get/set/misc. functions
public function hasSubcategory($id)
{
return !empty($this->subcategories[$id]);
}
public function hasSubcategories()
{
return is_array($this->subcategories) && !empty($this->subcategories);
}
public function getSubcategories()
{
return $this->subcategories;
}
}
I needed to get all categories and the result should reflect the visual tree
structure of the categories. With ORM (such as Hibernate), I could only get
back array($categoryObj) - PHP List<> equivalent. Which then forces me to
write extra code just to get a category which could be anywhere within the
tree structure. So I resort back to the standard DB abstraction + BO,
giving this result:
array ( $categoryObj->getId() => $categoryObject ) for all the categories
where each category's subcategories list is array ( $categoryObj->getId() =>
$categoryObject ) from a simple query 'select * from category'.
No loops just to find out if a category, anywhere within the tree structure,
has a subcategory:
$categories[$categoryObj->getId()]->hasSubcategory($subcategoryObj->getId)
or complex code to display the entire tree structure:
output($categories[0]->getsubcategories()) where output() is
function output($categoriesList)
{
echo '<ul>';
foreach ($categoriesList as $category)
{
// process each category;
echo '<li>'.$category->getName();
if ($category->hasSubcategories)
output($category->getSubcategories());
echo '</li>';
}
echo '</ul>';
}
A long time ago when I started coding PHP, the available IDEs didn't have
the capability to generate get/set methods from the properties of the class
like for Java. Thus, I made a utility, based on PHP of course, that will do
just that [1] which greatly reduces my developer time. I also have a
'mapper' that's an extension of my DB abstraction wrapper having this simple
code for the above example:
$this->connect();
$this->query($sqlString);
while($row = $this->fetch())
{
// map the row
}
$this->close();
Should the need ever arise, the abstraction wrapper I have will also permit
me to open more than 1 DB connection without breaking the existing code
while the code will still look similar to the above example. The above
sample code a slightly simpler than what I have, which ran against a more
sophisticated test case DB structure. Without caching, the final display
results in less than 1/2 sec to fetch from DB and display in HTML, both in
the header horizontal navigation bar and side bar tree for testing, having
over 3000 i18n categories with 7 levels deep. Displaying the 'norm' falls
within tens of milliseconds range.
Regards,
Tommy
PS: The tool has been slightly improved upon.
[1] http://pastebin.com/vMnFhpyf
--- End Message ---
--- Begin Message ---
On Thu, Dec 09, 2010 at 07:41:32PM -0800, Daevid Vincent wrote:
>
>
> > -----Original Message-----
> > > If you value CPU time over developer time, by all means avoid ORM
> > > frameworks (and *all* frameworks). The point of a common
> > framework is to
> > > trade a small bit of performance for a large amount of
> > developer time. If
> > > you will only use the framework once, the payoff will be
> > much less. The
> > > goal is to choose frameworks that you can leverage again and again.
>
[snip]
>
> That's just it. DO NOT make a "framework". Make some helper routines for
> common tasks like sql_query(), sql_insert(), sql_update(),
> sql_select_box(), etc. and stick to the "basics".
>
> Frameworks are a waste of time and energy -- homegrown or off-the-shelf.
> They try to be all things to all people and turn into a "jack of trades,
> master of none". They're bloated and cumbersome and force you to wedge
> square pegs into round holes all the time.
I have to agree with the "toolkit" idea.
I just came off of job where they had an existing investment in Drupal,
so we were stuck with it. No offense to any Drupalers out there. It's a
very slick, cleverly thought out framework. But building anything
non-trivial with the framework requires a significant learning curve and
coding investment. And many things you'll want to do, you could do ten
times faster by hand.
This is the second framework I've done any significant research into.
And my original decision to build a set of "tools" and use them for
various tasks over and over seems the soundest course. The more those
tools interlock, the more they become a framework, and the less flexible
they become.
The tools, used in a "habitual context" (models go here, views go there,
etc.) makes for a much easier time of it. Not to mention that your
thousands of site visitors won't be loading 150K of code each time just
to view one page. (Yes, I've heard of caching. It's a system which was
built to compensate for coders who waste too much CPU time and memory.)
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
On Dec 10, 2010, at 12:00 AM, Paul M Foster wrote:
> On Thu, Dec 09, 2010 at 07:41:32PM -0800, Daevid Vincent wrote:
>>
>>> -----Original Message-----
>>>> If you value CPU time over developer time, by all means avoid ORM
>>>> frameworks (and *all* frameworks). The point of a common
>>> framework is to
>>>> trade a small bit of performance for a large amount of
>>> developer time. If
>>>> you will only use the framework once, the payoff will be
>>> much less. The
>>>> goal is to choose frameworks that you can leverage again and again.
>>
>
> [snip]
>
>>
>> That's just it. DO NOT make a "framework". Make some helper routines for
>> common tasks like sql_query(), sql_insert(), sql_update(),
>> sql_select_box(), etc. and stick to the "basics".
>>
>> Frameworks are a waste of time and energy -- homegrown or off-the-shelf.
>> They try to be all things to all people and turn into a "jack of trades,
>> master of none". They're bloated and cumbersome and force you to wedge
>> square pegs into round holes all the time.
>
> I have to agree with the "toolkit" idea.
>
> I just came off of job where they had an existing investment in Drupal,
> so we were stuck with it. No offense to any Drupalers out there. It's a
> very slick, cleverly thought out framework. But building anything
> non-trivial with the framework requires a significant learning curve and
> coding investment. And many things you'll want to do, you could do ten
> times faster by hand.
>
> This is the second framework I've done any significant research into.
> And my original decision to build a set of "tools" and use them for
> various tasks over and over seems the soundest course. The more those
> tools interlock, the more they become a framework, and the less flexible
> they become.
>
> The tools, used in a "habitual context" (models go here, views go there,
> etc.) makes for a much easier time of it. Not to mention that your
> thousands of site visitors won't be loading 150K of code each time just
> to view one page. (Yes, I've heard of caching. It's a system which was
> built to compensate for coders who waste too much CPU time and memory.)
>
> Paul
I've used good ole' procedural PHP, built a homegrown "framework" and now I use
CakePHP, which has ORM. Yes, at first, it was a little confusing to understand.
But once you get it, it's really easy to create a database-driven, dynamic
application with little effort. Like most things in programming, you have to
find what works for you. While it is good to consider that others may have to
work with your _flawless_ code some day - so you better make it understandable
- many times clients just want what you can give them as soon as possible. What
I've found is that by using a framework (such as Cake) I am able to give the
client what they want... and quickly. If I ever run into a problem that can't
be easily solved by the framework, I resort to my experience with "direct PHP"
and just create a manual solution. That's the beauty of PHP.
CPU cycles are cheap and caching is there to speed things up, so I don't
completely understand those who complain about these things...
Happy coding,
~Philip
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Philip Thompson [mailto:philthath...@gmail.com]
> Sent: Thursday, December 09, 2010 10:59 PM
> To: php-general List
> Subject: Re: [PHP] ORM doctrine
>
> On Dec 10, 2010, at 12:00 AM, Paul M Foster wrote:
>
> > On Thu, Dec 09, 2010 at 07:41:32PM -0800, Daevid Vincent wrote:
> >>
> >>> -----Original Message-----
> >>>> If you value CPU time over developer time, by all means avoid ORM
> >>>> frameworks (and *all* frameworks). The point of a common
> >>> framework is to
> >>>> trade a small bit of performance for a large amount of
> >>> developer time. If
> >>>> you will only use the framework once, the payoff will be
> >>> much less. The
> >>>> goal is to choose frameworks that you can leverage again and again.
> >>
> >
> > [snip]
> >
> >>
> >> That's just it. DO NOT make a "framework". Make some helper routines
> >> for common tasks like sql_query(), sql_insert(), sql_update(),
> >> sql_select_box(), etc. and stick to the "basics".
> >>
> >> Frameworks are a waste of time and energy -- homegrown or off-the-
> shelf.
> >> They try to be all things to all people and turn into a "jack of
> >> trades, master of none". They're bloated and cumbersome and force you
> >> to wedge square pegs into round holes all the time.
> >
> > I have to agree with the "toolkit" idea.
> >
> > I just came off of job where they had an existing investment in
> > Drupal, so we were stuck with it. No offense to any Drupalers out
> > there. It's a very slick, cleverly thought out framework. But building
> > anything non-trivial with the framework requires a significant
> > learning curve and coding investment. And many things you'll want to
> > do, you could do ten times faster by hand.
> >
> > This is the second framework I've done any significant research into.
> > And my original decision to build a set of "tools" and use them for
> > various tasks over and over seems the soundest course. The more those
> > tools interlock, the more they become a framework, and the less
> > flexible they become.
> >
> > The tools, used in a "habitual context" (models go here, views go
> > there,
> > etc.) makes for a much easier time of it. Not to mention that your
> > thousands of site visitors won't be loading 150K of code each time
> > just to view one page. (Yes, I've heard of caching. It's a system
> > which was built to compensate for coders who waste too much CPU time
> > and memory.)
> >
> > Paul
>
> I've used good ole' procedural PHP, built a homegrown "framework" and
> now I use CakePHP, which has ORM. Yes, at first, it was a little confusing
to
> understand. But once you get it, it's really easy to create a
database-driven,
> dynamic application with little effort. Like most things in programming,
you
> have to find what works for you. While it is good to consider that others
may
> have to work with your _flawless_ code some day - so you better make it
> understandable - many times clients just want what you can give them as
> soon as possible. What I've found is that by using a framework (such as
> Cake) I am able to give the client what they want... and quickly. If I
ever run
> into a problem that can't be easily solved by the framework, I resort to
my
> experience with "direct PHP" and just create a manual solution. That's the
> beauty of PHP.
>
> CPU cycles are cheap and caching is there to speed things up, so I don't
> completely understand those who complain about these things...
>
> Happy coding,
> ~Philip
The way I see it is this:
1) Thorough understanding of the problem: needs of the client/company,
programming language in use, etc.
2) Thorough understanding of the objective of the application: answer the
needs, capable of possible future growth/expandability, etc.
3) Well thought out application design to resolve the above 2: framework,
mixed, or no framework.
Thus, IMHO, caching is needed when one fails to fully meet the above 3 such
as when the user clicks on any link in the browser, it should take no more
than 3 seconds for the browser's status to be 'Done', provided that the user
isn't on some 56k modem connection ;). (Naturally, the only exception to
that is dealing with reports for data mining where millions of rows are
involved. That's the DBA problem most of the time anyway.) Moreover, I see
the needs of applications now to be more event driven than database driven.
As of now, it's very rare to see an app w/o some kind of DB backend. Yes,
CPU cycles maybe cheap but electricity and rack space aren't. There's a
reason why Google chose to go with AMD rather than Intel a few years back
during their server farm upgrade. It was pretty much a slap in the face for
Intel when that decision made headline news.
Regards,
Tommy
--- End Message ---
--- Begin Message ---
I see that the ORM thread has generated a broad-ranging discussion. Some of
the posts have discussed the utility of frameworks and/or libraries, and
because it's Friday, I thought I'd toss out my observations on the subject
and see what ideas those on the list had regarding the subject.
Libraries and frameworks both offer the general hope that their carefully
crafted and maintained code is better than my one-off stab at the problem
will be within the timeframe I have to complete the project. However, I
tend to make a distinction between frameworks and libraries. Simply,
frameworks control the flow of the application, whereas libraries provide
functionality that fits into your applications flow.
On the homepage, Doctrine says it's a library, and that seems to fit with
the above distinction given my limited knowledge of the code. JQuery is a
javascript library, and, although Zend is called a framework, I tend to use
it as a library (SMTP email, etc.) to augment my own code, although it can
certainly be used as a framework. CakePHP, Ruby on Rails, and Code Igniter
are all frameworks because they control the flow of the app.
Martin Fowler has a nice blog post which speaks more clearly on the
distinction I tend to draw:
http://martinfowler.com/bliki/InversionOfControl.html
As one point of curiosity, I'm wondering when a function or group of
functions is, in your eyes, deemed a library. I tend to use the pornography
approach to identifying a library ("I know it when I see it"), but I'm sure
there's a more formal analysis. For some, maybe it's as simple as "The
developer calls this a library." :)
<http://martinfowler.com/bliki/InversionOfControl.html>Moving on, this
distinction between frameworks and libraries helps inform my choice of
tools. If there is a simple task that I'm going to perform and I know that
many before me have been faced with the same hurdle, I'll look for a
function. However, if there are a set of related tasks I'm going to
perform, I'll look for a library. If none is suitable/findable/trustable,
then I'll see what I can muster.
I use frameworks when there is a particular flow I wish to enforce
throughout the application. For instance, my web framework enforces a
general flow during all requests:
- Input validation on all incoming Get, Post, or Cookie variables, and
delete any not expected or accounted for.
- Short-circuiting of the request if the client only wants an html
fragment (one dynamic region of the page instead of the whole page, as is
used to update pages via Ajax.)
- Automatic output escaping, automatically adjusting for context.
Now, I could use libraries to get the same effect, certainly. However, I
prefer that this flow occur on every dynamic page, and a framework allows me
to easily achieve and enforce this flow. Are these the same reasons some of
you use frameworks?
I'm also curious if some of the custom "libraries" people have built fall
into the category of framework using the definitions above. C'mon, you can
'fess up, there aren't that many people listening :)
Last, I want to be clear and say that I'm not saying you should always use a
framework or library. Especially with frameworks, you have to be judicious
in your decision, as the same control of flow that can prove so helpful can
also wreak havoc when it takes you and your developers out of their standard
flow, and can make simple task into complex riddles Solomon couldn't solve.
It's nice that those on this list do such a solid job of arguing whether to
use frameworks or libraries or custom code, as this will better inform those
who are new to programming and/or PHP.
Adam
--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Adam Richardson [mailto:simples...@gmail.com]
> Sent: Friday, December 10, 2010 12:05 AM
> To: PHP-General
> Subject: [PHP] A general discussion of libraries and frameworks
>
> I see that the ORM thread has generated a broad-ranging discussion. Some
> of the posts have discussed the utility of frameworks and/or libraries,
and
> because it's Friday, I thought I'd toss out my observations on the subject
and
> see what ideas those on the list had regarding the subject.
>
> Libraries and frameworks both offer the general hope that their carefully
> crafted and maintained code is better than my one-off stab at the problem
> will be within the timeframe I have to complete the project. However, I
> tend to make a distinction between frameworks and libraries. Simply,
> frameworks control the flow of the application, whereas libraries provide
> functionality that fits into your applications flow.
>
> On the homepage, Doctrine says it's a library, and that seems to fit with
the
> above distinction given my limited knowledge of the code. JQuery is a
> javascript library, and, although Zend is called a framework, I tend to
use it
> as a library (SMTP email, etc.) to augment my own code, although it can
> certainly be used as a framework. CakePHP, Ruby on Rails, and Code
Igniter
> are all frameworks because they control the flow of the app.
>
> Martin Fowler has a nice blog post which speaks more clearly on the
> distinction I tend to draw:
> http://martinfowler.com/bliki/InversionOfControl.html
>
> As one point of curiosity, I'm wondering when a function or group of
> functions is, in your eyes, deemed a library. I tend to use the
pornography
> approach to identifying a library ("I know it when I see it"), but I'm
sure
> there's a more formal analysis. For some, maybe it's as simple as "The
> developer calls this a library." :)
>
> <http://martinfowler.com/bliki/InversionOfControl.html>Moving on, this
> distinction between frameworks and libraries helps inform my choice of
> tools. If there is a simple task that I'm going to perform and I know
that
> many before me have been faced with the same hurdle, I'll look for a
> function. However, if there are a set of related tasks I'm going to
perform,
> I'll look for a library. If none is suitable/findable/trustable, then
I'll see
> what I can muster.
>
> I use frameworks when there is a particular flow I wish to enforce
> throughout the application. For instance, my web framework enforces a
> general flow during all requests:
Adam,
I find that 'enforce' leads to inflexibility eventually. As for framework,
I'm still looking for a good implementation of the presented concept (MVC,
ORM, etc.). Case in point: MVC. You could just add or do some minor change
in either/all the Model, View, or Controller, having that flexibility to
adapt w/o major base code change is very nice. The problem lies therein of
implementing the abstract concept MVC into concrete, workable (learning,
understanding, maintaining, etc.), reliable, and flexible (modular, 3rd
party add-ins, etc.) code while retaining good performance. IE: Zend
Framework. The code base is somewhat bloated, IMO. But as others have
mentioned, it's still useful due to its modular design as you can choose to
use parts of it within your app and not need to implement the entire
framework. I don't have enough experience with ZF yet to see how
expandability it is in terms of third party add-in/plugin/module. Here's the
list of PHP frameworks [1]. I don't know how current it is. As you can see
from that table, only 2 supports everything that's current under the sun,
including template & event driven. Yii isn't very mature from what I've
read so far. PRADO's, although acronym is both catchy and meaningful, code
base is too much ASP.NET like even though it's based on PHP >.>.
Ironically, both projects are started by the same person.
Regards,
Tommy
[1] http://www.phpframeworks.com/
>
> - Input validation on all incoming Get, Post, or Cookie variables, and
> delete any not expected or accounted for.
> - Short-circuiting of the request if the client only wants an html
> fragment (one dynamic region of the page instead of the whole page, as
is
> used to update pages via Ajax.)
> - Automatic output escaping, automatically adjusting for context.
>
> Now, I could use libraries to get the same effect, certainly. However, I
> prefer that this flow occur on every dynamic page, and a framework allows
> me to easily achieve and enforce this flow. Are these the same reasons
> some of you use frameworks?
>
> I'm also curious if some of the custom "libraries" people have built fall
into
> the category of framework using the definitions above. C'mon, you can
'fess
> up, there aren't that many people listening :)
>
> Last, I want to be clear and say that I'm not saying you should always use
a
> framework or library. Especially with frameworks, you have to be
judicious
> in your decision, as the same control of flow that can prove so helpful
can
> also wreak havoc when it takes you and your developers out of their
> standard flow, and can make simple task into complex riddles Solomon
> couldn't solve.
>
> It's nice that those on this list do such a solid job of arguing whether
to use
> frameworks or libraries or custom code, as this will better inform those
who
> are new to programming and/or PHP.
>
> Adam
>
> --
> Nephtali: PHP web framework that functions beautifully
> http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
On 10 December 2010 12:07, Tommy Pham <tommy...@gmail.com> wrote:
> Ironically, both projects are started by the same person.
So that old adage of there being at least 2 PHP frameworks per PHP
developer still holds true!
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
From: Adam Richardson
> As one point of curiosity, I'm wondering when a function or group of
> functions is, in your eyes, deemed a library. I tend to use the
pornography
> approach to identifying a library ("I know it when I see it"), but I'm
sure
> there's a more formal analysis. For some, maybe it's as simple as
"The
> developer calls this a library." :)
As soon as you bundle a set of functions into a separate package that
can be shared between projects, developers or teams, you have a library.
I believe this is true even if there is only a single function in the
bundle. Some libraries are quite extensive, and may even include a
complete framework. But the distinction is the bundling that makes them
independent of any specific project.
> I'm also curious if some of the custom "libraries" people have built
fall
> into the category of framework using the definitions above. C'mon,
you can
> 'fess up, there aren't that many people listening :)
Yes, I would accept that some frameworks are distributed as libraries.
The distinction is where do you start? A library of functions can be
added to your application as you go along. But a framework pretty much
has to be the starting point for a project. When you use Drupal, you
start by setting up a Drupal server. Then you add your own pages or
maybe a custom module. The same goes for most of the other frameworks.
You start with the framework and develop your application within it.
Bob McConnell
--- End Message ---
