[PHP] Scalable Vector Graphics with PHP

[sudarshana sampath]

Hi,

We are going add a topology view to our Network Management System.
Our Network Management System is based on PHP, CakePHP, jQuery and other web
related tools(middle tier written using C++).

So we are going to work with Scalable Vector Graphics.

We are looking for the best solution for doing that.

Are there any extensions, plugins, frameworks available for SVG related
things ?

Any help is much appreciated.

-- 
Cheers,
Sudarshana Sampath.

Re: [PHP] Scalable Vector Graphics with PHP

[Nathan Nobbe]

On Thu, Dec 9, 2010 at 4:55 AM, sudarshana sampath <
sudarshanasamp...@gmail.com> wrote:

> Hi,
>
> We are going add a topology view to our Network Management System.
> Our Network Management System is based on PHP, CakePHP, jQuery and other
> web
> related tools(middle tier written using C++).
>
> So we are going to work with Scalable Vector Graphics.
>
> We are looking for the best solution for doing that.
>
> Are there any extensions, plugins, frameworks available for SVG related
> things ?
>

not sure exactly what youre trying to accomplish, but obviously you could
use any number of vector programs over the cli from php.

you might also have a peak at the cairo library which php allegedly supports
(ive never tried it myself).

http://us.php.net/manual/en/intro.cairo.php

-nathan

[PHP] sending emails

[Marc Fromm]

We have web forms that send the user an email confirmation after submission, 
like most forms do.
The emails are being delivered to the users' junk folder. The main campus IT 
staff claim it is because our server is sending the emails.
The campus is using Microsoft exchange servers. I am using Red Hat Linux, 
sendmail, and PHP. Is there a way to give php the exchange server's ip address 
and have the emails from my php forms be sent from the exchange server?

Thanks

Marc

Re: [PHP] ORM doctrine

[David Harkness]

On Wed, Dec 8, 2010 at 11:11 PM, Daevid Vincent  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

Re: [PHP] sending emails

[Daniel P. Brown]

On Thu, Dec 9, 2010 at 13:36, Marc Fromm  wrote:
> We have web forms that send the user an email confirmation after submission, 
> like most forms do.
> The emails are being delivered to the users' junk folder. The main campus IT 
> staff claim it is because our server is sending the emails.
> The campus is using Microsoft exchange servers. I am using Red Hat Linux, 
> sendmail, and PHP. Is there a way to give php the exchange server's ip 
> address and have the emails from my php forms be sent from the exchange 
> server?

Unfortunately, folks don't seem to read the archives anymore

Marc, check the archives to see answers to this question even this
month.  Some have recommended PEAR packages, others have recommended
other packages and methods, and for one particular instance, I
recommended using the fifth parameter of the mail() function to pass
the '-f' flag to Sendmail.

That said, unless there's more to the story, there should be no
reason why your server shouldn't deliver email.  Shared hosting, for
example, most often provides both SMTP and POP3 in addition to hosting
the actual website(s), and is used exclusively in most cases for all
services for a given account.

-- 

Dedicated Servers, Cloud and Cloud Hybrid Solutions, VPS, Hosting
(866-) 725-4321
http://www.parasane.net/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] sending emails

[Ashley Sheridan]

On Thu, 2010-12-09 at 10:36 -0800, Marc Fromm wrote:

> We have web forms that send the user an email confirmation after submission, 
> like most forms do.
> The emails are being delivered to the users' junk folder. The main campus IT 
> staff claim it is because our server is sending the emails.
> The campus is using Microsoft exchange servers. I am using Red Hat Linux, 
> sendmail, and PHP. Is there a way to give php the exchange server's ip 
> address and have the emails from my php forms be sent from the exchange 
> server?
> 
> Thanks
> 
> Marc
> 
> 


PHP can connect to an SMTP server if the Exchange server will allow a
connection to be made from it. Nothing is standard with Exchange (or
Microsoft in general really), so it could be more effort than it's
worth.

Having a message filtered to the Junk folder could be caused from
several things, either the text to image ratio isn't high enough, you're
using words considered "spammy" (steer clear of the typical words you
see in your own Junk box), the IP address you're sending from is on a
blacklist, the receiving server sees that the from address resolves to a
different IP than the server sending the email, among other reasons.

If the recipients are all on the same Exchange server, then you can have
your Linux servers IP address added to a whitelist which should ensure
all your email gets through correctly.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] sending emails

[TR Shaw]

On Dec 9, 2010, at 1:36 PM, Marc Fromm wrote:

> We have web forms that send the user an email confirmation after submission, 
> like most forms do.
> The emails are being delivered to the users' junk folder. The main campus IT 
> staff claim it is because our server is sending the emails.
> The campus is using Microsoft exchange servers. I am using Red Hat Linux, 
> sendmail, and PHP. Is there a way to give php the exchange server's ip 
> address and have the emails from my php forms be sent from the exchange 
> server?


Marc

Use phpmailer.

Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] sending emails

[Ashley Sheridan]

On Thu, 2010-12-09 at 14:03 -0500, TR Shaw wrote:

> On Dec 9, 2010, at 1:36 PM, Marc Fromm wrote:
> 
> > We have web forms that send the user an email confirmation after 
> > submission, like most forms do.
> > The emails are being delivered to the users' junk folder. The main campus 
> > IT staff claim it is because our server is sending the emails.
> > The campus is using Microsoft exchange servers. I am using Red Hat Linux, 
> > sendmail, and PHP. Is there a way to give php the exchange server's ip 
> > address and have the emails from my php forms be sent from the exchange 
> > server?
> 
> 
> Marc
> 
> Use phpmailer.
> 
> Tom


Would that stop the email being seen as spam? Depending on the root
issue, probably unlikely, as there are countless reasons an email could
be seen as spam, the majority of which wouldn't be fixed by something
like phpmailer.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] sending emails

[Steve Staples]

On Thu, 2010-12-09 at 19:06 +, Ashley Sheridan wrote:
> On Thu, 2010-12-09 at 14:03 -0500, TR Shaw wrote:
> 
> > On Dec 9, 2010, at 1:36 PM, Marc Fromm wrote:
> > 
> > > We have web forms that send the user an email confirmation after 
> > > submission, like most forms do.
> > > The emails are being delivered to the users' junk folder. The main campus 
> > > IT staff claim it is because our server is sending the emails.
> > > The campus is using Microsoft exchange servers. I am using Red Hat Linux, 
> > > sendmail, and PHP. Is there a way to give php the exchange server's ip 
> > > address and have the emails from my php forms be sent from the exchange 
> > > server?
> > 
> > 
> > Marc
> > 
> > Use phpmailer.
> > 
> > Tom
> 
> 
> Would that stop the email being seen as spam? Depending on the root
> issue, probably unlikely, as there are countless reasons an email could
> be seen as spam, the majority of which wouldn't be fixed by something
> like phpmailer.
> 

If it were me, I'd use something like PHPMailer with SMTP
Authentication, which then the email comes from the "MailServer" rather
than the "WebServer" if they are 2 separate machines.

That COULD solve the issue there, but as Ash said, if it has "spammy"
words in it, it wouldn't make any difference then.

Try using the "-f" flag with the PHP mail(), and if that doesn't work,
then try a 3rd party class such as PEAR::Mail, or PHPMailer.

Steve



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] sending emails

[TR Shaw]

On Dec 9, 2010, at 2:06 PM, Ashley Sheridan wrote:

> On Thu, 2010-12-09 at 14:03 -0500, TR Shaw wrote:
>> 
>> On Dec 9, 2010, at 1:36 PM, Marc Fromm wrote:
>> 
>> > We have web forms that send the user an email confirmation after 
>> > submission, like most forms do.
>> > The emails are being delivered to the users' junk folder. The main campus 
>> > IT staff claim it is because our server is sending the emails.
>> > The campus is using Microsoft exchange servers. I am using Red Hat Linux, 
>> > sendmail, and PHP. Is there a way to give php the exchange server's ip 
>> > address and have the emails from my php forms be sent from the exchange 
>> > server?
>> 
>> 
>> Marc
>> 
>> Use phpmailer.
>> 
>> Tom
> 
> Would that stop the email being seen as spam? Depending on the root issue, 
> probably unlikely, as there are countless reasons an email could be seen as 
> spam, the majority of which wouldn't be fixed by something like phpmailer.
> 
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
> 
> 

Ash,

I can only react to what he said eg their IT staff said it is because it comes 
from his server.

Yes you could ask the IT staff to whitelist their server but my experience with 
corporate, government and university IT is that its easier and quicker not to 
ask them to do much of anything.

phpmailer will allow him to send authenticated via his exchange server via SMTP 
Auth thus not requiring IT to do much of anything other than to add another 
user (and yes he can auth via his own account and send anyway but using an 
auditable user is a much better approach). 

Although I agree that there might be many reasons from the mail to be declared 
"spammy" his IT indicated that it was IP/source related and the approach above 
solves that problem by making the mail "local."

He can always look at the headers to see why it was declared "spammy" if he 
doesn't trust his IT department.

Tom

[PHP] PHP 5.3.4 Released

[Johannes Schlüter]

The PHP development team is proud to announce the immediate release of
PHP 5.3.4. This is a maintenance release in the 5.3 series, which
includes a large number of bug fixes.

Security Enhancements and Fixes in PHP 5.3.4:
  * Fixed crash in zip extract method (possible CWE-170).
  * Paths with NULL in them (foo\0bar.txt) are now considered as
invalid (CVE-2006-7243).
  * Fixed a possible double free in imap extension (Identified by
Mateusz Kocielski). (CVE-2010-4150).
  * Fixed NULL pointer dereference in ZipArchive::getArchiveComment.
(CVE-2010-3709).
  * Fixed possible flaw in open_basedir (CVE-2010-3436).
  * Fixed MOPS-2010-24, fix string validation. (CVE-2010-2950).
  * Fixed symbolic resolution support when the target is a DFS
share.
  * Fixed bug #52929 (Segfault in filter_var with
FILTER_VALIDATE_EMAIL with large amount of data)
(CVE-2010-3710).

Key Bug Fixes in PHP 5.3.4 include:
  * Added stat support for zip stream.
  * Added follow_location (enabled by default) option for the http
stream support.
  * Added a 3rd parameter to get_html_translation_table. It now
takes a charset hint, like htmlentities et al.
  * Implemented FR #52348, added new constant ZEND_MULTIBYTE to
detect zend multibyte at runtime.
  * Multiple improvements to the FPM SAPI.

Over 100 other bug fixes.

For users upgrading from PHP 5.2 there is a migration guide
available on , detailing the changes between
those releases and PHP 5.3.

For a full list of changes in PHP 5.3.4, see the ChangeLog on
. For source downloads
please visit our downloads page on ,
Windows binaries can be found on .

Johannes Schlüter
PHP 5.3 Release Master



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] PHP 5.2.15 Released!

[Ilia Alshanetsky]

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
. For source downloads please
visit our downloads page on ,
Windows binaries can be found on .


Ilia Alshanetsky
5.2 Release Master

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] ORM doctrine

[Larry Garfield]

On Thursday, December 09, 2010 12:45:38 pm David Harkness wrote:
> On Wed, Dec 8, 2010 at 11:11 PM, Daevid Vincent  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

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] ORM doctrine

[Daevid Vincent]

 

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


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] ORM doctrine

[Tommy Pham]

> -Original Message-
> From: Larry Garfield [mailto:la...@garfieldtech.com]
> Sent: Thursday, December 09, 2010 5:35 PM
> To: php-general@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 
> 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 '';
  foreach ($categoriesList as $category)
 {
// process each category;
   echo ''.$category->getName();
   if ($category->hasSubcategories)
  output($category->getSubcategories());
   echo '';
  }
  echo '';
}

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

Re: [PHP] ORM doctrine

[Paul M Foster]

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

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] ORM doctrine

[Philip Thompson]

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