On Sep 23, 2007, at 9:20 PM, jtaber wrote:
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.
The fact that you don't see them doesn't mean they doesn't exist. :)
So you're complaint is that unit testing isn't built into the
language? I suppose the answer to that is that everyone likes their
testing in different flavors. I suppose there are advantages and
disadvantages to that. I can see if you don't like that - and that's
fine.
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.
This is seriously your biggest problem with PHP? I can think of
things I don't like, but this is most definitely not in the top ten.
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?
http://www.php.net/manual/en/function.ob-start.php
It just stores the output in a buffer until you want to do something
else with it - it's not really all that complicated. Again, this has
*nothing* to do with PHP, but whatever crappy code you're using for
PHP application development. There's *nothing* preventing a well-
written front-controller in PHP. If you're having these problems,
it's because of someone misusing base functions in PHP.
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.
Again, you seem to be stuck on the fact that "PHP" is some generic
framework we all use.
When the gods created Django and Rails, they used Ruby and Python to
set up a way to automatically escape stuff going into SQL queries.
The PHP gods have blessed me with that same magic. If you say "PHP"
can't do this, you're not using the right PHP *framework.*
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.
I don't like either of the options I've listed either. Again, this is
just a matter of finding or writing something in PHP that works for
what you need.
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.
No, they are not. If you're not willing to concede this, there really
isn't any more we can discuss. What if I use some crappy Ruby
framework and use it as a straw man for all PHP vs. Ruby arguments?
That'd be retarded. I could say all sorts of things that have nothing
to do with Ruby and everthing to do with my badly implemented framework.
You've got to compare apples with apples.
PHP is not an approach to development. It's a scripting language. You
can use PHP to develop sys admin scripts and GTK applications just
like you can use Ruby for a wide array of applications. They are base
tools for implementations of a methodology. Rails is a methodology on
top of Ruby. PHP is not a methodology, it's a tool that can be used
to implement one.
PHP is most definitely not a web framework. I use a PHP MVC framework
I really enjoy that suffers from none of the drawbacks you've
outlined. None. It can be done in PHP.
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.
Firefox's Mozilla Addons page was done using the same PHP framework I
use. The next version of Mambo is going to be using it. I'm using it
for a global application.
Are you referring to a particular framework when you say Rails and
Django are more stable, or are you making a blanket statement? What
reason do you have to say that, exactly? I don't think I can speak
for "the market," but I have little concern about the code I'm using
right now.
I'm using a *development* branch of my framework, and it has been
solid for a clustered app we're in beta testing on. My experience is
very different from yours.
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.
Maybe you should investigate a particular PHP framework, rather than
viewing it as one generic mass of development. There are a billion
different ways to approach this problem, and I feel treating PHP like
a lump sum isn't a great way to see what can happen with it.
-- John
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
