John David Anderson wrote:
On Sep 23, 2007, at 2:21 PM, jtaber wrote:
1) Lack of Built In Testing - I guess there are some external tools
like UnitTest but nothing as easy as in Rails. And sites without
testing, well....
There are hordes of PHP unit test packages. PHPUnit, SimpleTest. I
don't believe Rails' testing is any better or worse than PHP-flavored
offerings.
Perhaps I'm mistaken but my point was not that it's not available, but
that it's not built in so everyone on the team is both using it and in
the same way. Every time you have to add this external program or add
that package, the learning curve and time and complexity goes up. I
see so few articles about test driven development or agile programming
with PHP examples.
2) Lack of Good Redirecting - Rails uses a great front-end controller
and it's simple to call redirects and linktos from anywhere. PHP has
some real restrictions with redirects (ie before html output, etc).
You can buffer output if you need to. It's not a PHP-limitation: that
location *header* has to come before anything else. There's nothing
PHP or Ruby specific there. Code it up different if you want.
This was our biggest problem with PHP and why we're not using it today -
we were constantly getting error messages with location headers. In
Rails/Django it just isn't a problem - to be honest, I don't know what
the difference is - I'm assuming it has to do with the front-end
controller. I don't know what you mean by "buffering" - sounds
complicated, but can you give an example?
3) Lack of Good Data Protection/Integrity - simple things like
built-in protection against injection attacks
Who cares what language you code in to prevent SQL-based attacks? I
don't see how Ruby or PHP would really differ at all. You could
probably create a safe website in BASIC if you wanted to. I don't
think you can say that Ruby is "safer" than PHP or Java or whatever.
Again, it's just built in with Rails and Django helpers - you have to
code it in with PHP - more time, more effort, more inconsistency. I
don't want to have to read a whole book on how to prevent it - I havent'
seen any simple examples how to code it right in a generic PHP model class.
4) ORM - actually this is more questionable but ORM comes in really
handy in things like views where you don't need to do
lookups/retrieval to show something like invoice.customer.name
You can't have ORM with PHP? I've been using packages that do that for
a long time. Most frameworks come with something, and there are
stand-alone packages like Doctrine and Propel.
Propel might indeed be a good choice for this but when I first looked
into it, it just seemed like lots of extra work without good examples.
The lack of these things make us much more productive in Rails or
Django than in PHP.
Rails and Django are not languages. Please compare apples to apples.
It's like saying Scrum and XP are more productive than English.
Wrong, it is fair to compare PHP language coding with the Rails
framework because both are "approaches" to web development. And frankly
when it comes to the PHP frameworks both Rails and Django seem to be
more stable, more featured, so to me the logical "approach" is either
Rails, Django, or straight PHP coding. Haven't seen any major sites
using any of the PHP frameworks so I think the market feels the same.
I think the choice of PHP over Ruby is a deployment based issue. I
don't see how
There's no question that deployment is the achillies heel of Rails - no
matter what the Rails guys say, it's hard. Django is less hard. The
CDBaby author was spot on here and why we keep the door open to PHP.
Finally , let me say I'm always looking for the fastest, simplest, and
best way to get our applications done. So far, I have yet to find the
approach that I feel is great. These were the hang-ups with PHP that I
thought the CDBaby author overlooked and why we've found Rails and
Django to be less bad. I keep looking to be proven wrong.
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
