Which PHP5 Framework is Your Favorite?

matt_j_99 asks: "With all the talk about Ruby on Rails, I've been thinking about PHP frameworks. Ruby on Rails looks pretty cool, but frankly, I don't want to learn a new language. It seems that with all the slashdot discussion about RoR, somebody always makes the valid point that PHP is not a framework. But with PHP5's, Object Oriented features, a standard framework might emerge. Prado, Carthag, BlueShoes, and PHITE all seem like interesting frameworks. What PHP frameworks have you used in your applications? What were the pros and cons of each? Which framework do you think will have the best chance of long-term viability and maintenance?"

Comments

Pretty obvious answer

[rylin]

Our in-house framework, as it does precisely everything we need - no more, no less.

Re:Pretty obvious answer

[LuckyStarr]

We must use the same framework, as mine does exactly the same.

Re:Pretty obvious answer

[rylin]

GASP! You've stol^H^H^H^Hcopied our codebase?
Prepare to be sued into the next millenium!

Re:Pretty obvious answer

[KILNA]

Indeed. You have the choice of someone else's idea of what features and work-flow you need, or your own. Writing wrapper classes for output, databases, etc. isn't that hard, and you can get a solution 100% tailored to you needs.

The only argument I could imagine for using someone else's framework is to reduce the overhead to bring in new programmers since they'll already know much of the ropes. But in the case of PHP there really isn't a clear winning system with a large pool of available programmers...

PHP? Switch to Python and Django

[Boffy]

I've been exclusively PHP for a number of years now, but the lack of innovation in frameworks and the OO limitations in PHP have lead me to Python. Python has a great up-and-coming framework called Django which was covered on slashdot recently. I've switched over to this and can see my productivity shooting right up once I've got to grips with it

Re:PHP? Switch to Python and Django

[ciroknight]

No offense, but that's pretty trollish. The article specifically mentions that he wants to do things with PHP and not Ruby on Rails, and since Django is Ruby on Rails for Python, you're not helping.

As for my contribution: I've worked a *miniscule* bit with Prada and I really didn't like it. But you might find it to your own liking. Different strokes for different folks I guess.

Re:PHP? Switch to Python and Django

[yasth]

I think django might still be little bit raw to be used in production. I mean they don't have an official version yet for crying out loud. It is really cool though.

Re:PHP? Switch to Python and Django

[Boffy]

The roadmap is coming along. It's basically feature complete, they're just fixing bugs at the moment and sorting some usability issues. I'm using the development version for a small project to get to grips with it before I use the release version for my main project. By the time you're ready for any serious stuff, I expect 1.0 will be ready. It's not gonna be one of these OSS things that stays in beta forever

lame excuse

[namekuseijin]

"I don't want to learn a new language"

how about learning a true language like Ruby rather than continue with a subpar Perl reject like PHP?

Re:lame excuse

[namekuseijin]

how about learning a modern, multi-paradigm, very higher-level language for rapidly developing business apps like Ruby rather than an ancient portable assembly to build infrastructure like C?

Re:lame excuse

[mattyrobinson69]

troll? jesus, he's right.

Re:lame excuse

[D'Sphitz]

How about just accepting that while Ruby may suit your needs just fine, most people aren't interested. Then you can quit wandering around all pissed off at everyone because they don't use Ruby, and be happy that you use Ruby even though other people prefer Python or PHP.

Seriously, is Ruby some kind of a cult or something? I thought mac zealots were bad, but everytime a scripting language is mentioned the ruby enthusiasts come out with such hate for everything non-Ruby. Get a grip.

Re:lame excuse

[Santana]

How about learning a "real" language like C, rather than a script piece of shit like Ruby?

how about learning a modern, multi-paradigm, very higher-level language for rapidly developing business apps like Ruby rather than an ancient portable assembly to build infrastructure like C?

I don't see the zealotry nor the cult here. He replied to a troll, with a nice summary of Ruby features not found in C.

You get a grip

Re:lame excuse

[ciroknight]

Oh you mean like Visual Basic.. I tried it and it sucked.

I find that even if it takes a bit longer to code, you will get better results out of C/C++/ObjC. Objective C is slowly but surely gaining momentum in my programming portfolio as I think "hey, that'd be easier to do in ObjC than it would C++".

As for scripting, PHP is pretty good now. It used to be trashy, but version 4 and 5 are very nice, easy to work with, and reasonably fast. Python's not my cup of tea (little too much like Java for me, and I really don't like my "language" to include a library for everything; I can find my own and include them or write my own). Ruby would be interesting to learn, but I doubt if I'd ever use it for anything.

Inevitably, as higher level languages are written in C, you're almost always going to find that you get better performance out of a comparable C app. But I guess if you're looking for speed of development and don't really mind if the language dies in the next ten years, Ruby or Python will work for you. Meanwhile my C app will be maintainable by the newest upstarts to the oldest of the oldies.

Re:lame excuse

[namekuseijin]

i said "modern, multi-paradigm, very higher-level language", not a "severely patched M$ offering for a very old, simple and basic language for beginners", not unlike PHP btw.

"find that even if it takes a bit longer to code, you will get better results out of C/C++/ObjC."

"Inevitably, as higher level languages are written in C, you're almost always going to find that you get better performance out of a comparable C app."

ah! the "slow performance" argument, easily refutable by noticing that most performance bottlenecks in systems come external factors like file system, DBMSs, network etc; and also that most libraries for such languages are just ( mostly thin ) wrappers for native libs.

"As for scripting, PHP is pretty good now. It used to be trashy, but version 4 and 5 are very nice, easy to work with, and reasonably fast."

it really isn't: it's still a mess of a language with no support for modularization other than OO classes or relying on shallow naming conventions for functions in the global namespace.

"Python's not my cup of tea (little too much like Java for me, and I really don't like my "language" to include a library for everything; I can find my own and include them or write my own). Ruby would be interesting to learn, but

"I doubt if I'd ever use it for anything."

you won't. remember the mantra: "right tool for the right job"

"don't really mind if the language dies in the next ten years, Ruby or Python will work for you. Meanwhile my C app will be maintainable by the newest upstarts to the oldest of the oldies"

FUD. plain and simple. your C app from 10 years ago most likely depends heavily on external 3rd -party libraries that may be hard or impossible to either find or make them work today.

Python, Ruby and company are open-source projects with already more than 10 years old and are likely to stay.

Re:lame excuse

[google]

I suppose Ruby could be a cult, as evidenced by the fact that Ruby can be used to lure Genine Garafalo into your unicorn garden... or something like that.

But does Ruby like koolaid? I don't know. I just don't know.

To be honest, I've been using Ruby in a zen-like trance to help me attain my buddha-hood, so I haven't watched these in awhile.

uh-oh

[Santana]

but frankly, I don't want to learn a new language

That's the worst thing that can happen to a professional (assuming you are one): not willing to learn new things. I strongly recommend you to learn Ruby, "it puts the fun back on programming", you won't regret.

Re:uh-oh

[imgumbydammit]

I dunno, I can sympathize with that sentiment. Sometimes it's better to build on something you already know, rather than start over at the bottom learning what might seem to be yet another flavour of the month language.

Re:uh-oh

[RevAaron]

Yeah. Or learn Smalltalk, where you have all the power of Ruby, in it's pure, mature and untainted form. Or, maybe a Ruby user could try to learn it. FUN! Actually put the fun back in coding...

Re:uh-oh

[downward dog]

I switched from PHP to Ruby after reading the Pragmatic Programmer's tip to learn a new language every year. Learning new languages makes you a better programmer, and Ruby is a great language to learn.

After only a few months using Ruby on Rails, I can't imagine trying to manage a large project in PHP. My attempts at OOP resulted in huge classes (100+ lines), my code wasn't reusable, unit testing was nonexistent, and adding functionality to an existing page usually meant breaking the rest of the application. I'm sure that there are better programmers out there than I was, who can avoid these problems while using PHP. That is fine. But Ruby and Rails helped me to become a dramatically better programmer.

Re:uh-oh

[mangu]

I strongly recommend you to learn Ruby, "it puts the fun back on programming", you won't regret.

Do you have any more compelling arguments than that? The first time I read about Ruby I was interested. Now, by the 10000th time I read how much better Ruby is, without any specific reason other that some people love it so much, I'm pretty bored.

And, BTW, you are way off topic. This article is about PHP frameworks. Let me explain to you. PHP is considered by some to be an excellent language. However, differently from Ruby, PHP users are ready to acknowledge its shortcomings. So, how can we make PHP a better language? Frameworks are one kind of solution.

Ruby users are like "Hey guys, Ruby is better!!!", PHP users are like "Let's see, how can we improve PHP?". Guess which language will be a better solution in the end?

Re:uh-oh

[Mr. Slippery]

resulted in huge classes (100+ lines)

Did you leave a 0 out of that? Or is most of your programming done in trivial problem domains where a 100 line class can do something? (Or have you been infected with one of the object obfuscated memes where one useful class must be shattered into several smaller ones to fit some arbitary idea of proper module size?)

unit testing was nonexistent

Err, if you don't write unit tests, whose fault is that? I don't see how language choice helps with that.

and adding functionality to an existing page usually meant breaking the rest of the application.

Encapsulation. Learn it. Love it. Live it.

Re:uh-oh

[Anonymous Coward]

Ruby users are like "Hey guys, Ruby is better!!!", PHP users are like "Let's see, how can we improve PHP?". Guess which language will be a better solution in the end?

Henry Fort was like "Hey guys, automobiles are better!" Blacksmiths were like "Let's see, how can we improve horseshoes?". Guess how many non-Amish Americans still use a horse and cart?

(Of course, Ruby still has disadvantages, like being dog slow and lacking static checks. But while it's not quite on the level of your Haskells and MLs, it's still a million times better than PHP, which is just about the worst language in general use today.)

Re:uh-oh

[downward dog]

So what was it about my post that set you off? Or are you just having a bad day?

Did you leave a 0 out of that? Or is most of your programming done in trivial problem domains where a 100 line class can do something? (Or have you been infected with one of the object obfuscated memes where one useful class must be shattered into several smaller ones to fit some arbitary idea of proper module size?)

Yes, you can do something with 100+ line classes. (Notice that 500 lines is larger than 100 lines, and would therefore be 100+ lines.) My entire point was that with Ruby on Rails, I was able to do a lot with 5 to 25 line classes, which tends to make development and maintenance more manageable. Three lines of Active Record code can duplicate 300+ lines of PHP. Which would you rather write?

Re:uh-oh

[Mr. Slippery]

Yes, you can do something with 100+ line classes. (Notice that 500 lines is larger than 100 lines, and would therefore be 100+ lines.)

Uh, yeah. My point of contention was that 100 lines makes a "huge" class.

Three lines of Active Record code can duplicate 300+ lines of PHP. Which would you rather write?

Depends. Dunno "Active Record" from a hole in the ground, but I've had plenty of experience with packages that only take 3 lines to give you almost what 300 lines would otherwise do, and somewhere down the line you end up writing most of those other 297 lines to handle the edge cases.

Re:uh-oh

[mysticgoat]

I also go along with the sentiment (of sometimes wanting to avoid learning yet another language).

This can be summed up with the question: "Is this guy a programmer with ten years' experience, or a programmer who has repeated one year of experience ten times over?"

As Grasshopper plans his career it can be good if he asks himself how others will see him in a few years.

Re:uh-oh

[mangu]

Henry Fort was like "Hey guys, automobiles are better!" Blacksmiths were like "Let's see, how can we improve horseshoes?". Guess how many non-Amish Americans still use a horse and cart?

Funny typo, perhaps you were thinking about Charles Fort?

But, if you really meant Henry Ford, he fell in love so much with his Model T that General Motors have sold more cars than Ford in every year since 1927. Ford was unable to view objectively his own creation and realize that it wasn't perfect, while Chevrolets were improving from year to year.

it's still a million times better than PHP, which is just about the worst language in general use today

Can you explain in a few words why Ruby is so superior? Can you explain why PHP is worse than, for instance, Visual Basic, Fortran, or Cobol? If it's so obvious, it should be very easy to demonstrate.

Re:uh-oh

[ibbey]

And, BTW, you are way off topic. This article is about PHP frameworks. Let me explain to you. PHP is considered by some to be an excellent language. However, differently from Ruby, PHP users are ready to acknowledge its shortcomings. So, how can we make PHP a better language? Frameworks are one kind of solution.

Well, we're not really THAT far off topic. The reason that the OP doesn't want to use Rails is that they don't want to learn another language. That's a good reason on the surface, but to those of us who have made the leap, it's absurd. As many have pointed out, if you know PHP or Perl, the learning curve of Ruby is really shallow. You can get the basics in a few hours, and be quite proficient in a few weeks. And once you've taken the leap, you WILL be more efficient on 99% of tasks. So rather then being off topic, we are pointing out that the entire question is based on a flawed premise.

I'm not qualified to really explain the technical advantages & disadvantages of Ruby vs. PHP. But there's a high level overview of what's great about Ruby on the Ruby website. If you want more, the first edition of the excellent Programming Ruby is available for free online. You could easily scan through the first chapter in half an hour, and it touches on all the major parts of the language. If you're honest about your curiosity about Ruby, then I highly recommend you spend a few minutes & scan the online docs. You won't be disappointed.

Re:uh-oh

[ibbey]

This argument falls flat pretty quick. You don't need to abandon everything else you've learned to learn a new language. I'm not arguing that you need to learn every new language that comes along, but spending an hour learning -about- a new language is quite reasonable. Once you've done that, you can make a reasonable decision about whether you should continue and learn more.

Every language has advantages & disadvantages. I love Ruby & Rails, but for some jobs, I'll still use PHP. Some jobs are best suited to Perl, and some to C. A good programmer will be able to choose the best tool for the job at hand. Remember, all four of these languages have the same underlying inspirations, so once you know one, it's much easier to learn another. If you're a good PHP or Perl programmer, you can be a competent Ruby programmer in a week with some effort. Do you truly believe that your career & programming ability will be better served by NOT making that effort? If so, that's fine, that just leaves more jobs for the rest of us.

Re:uh-oh

[ibbey]

Ruby users are like "Hey guys, Ruby is better!!!", PHP users are like "Let's see, how can we improve PHP?". Guess which language will be a better solution in the end?

Yep, you're right. Us Ruby users are just sitting on our asses cheering, not actually improving anything. Oh, wait. No, we're not. The entire Rails environment is only about a year old, and is advancing literally every day. The core ruby language has been at the same version number for a while now, but there is a new version on the near horizon, all of the supporting technologies have advanced greatly in the meantime. Ruby might or might not be as successful as many of us believe, but it's not going to go away no matter how much you want it to.

Re:uh-oh

[Atzanteol]

Is it good for a "professional" to just ignore the parameters of a problem and answer with what they wish were the question?

Not all companies 'sanction' all languages. I typically don't have much of a choice on language when doing my job. What makes you think everyone else does? What the hell is wrong with you Ruby zealots?

Re:uh-oh

[Santana]

Is it good for a "professional" to just ignore the parameters of a problem and answer with what they wish were the question?

What are you talking about?

Not all companies 'sanction' all languages. I typically don't have much of a choice on language when doing my job. What makes you think everyone else does?

What makes you think I'm thinking everyone else can choice his/her language? Anyways, the OP clearly *can* choice his language. He's just too lazy to learn another one. And that's what I'm replying to.

What the hell is wrong with you Ruby zealots?

The only Ruby-specific in my post is the suggestion to learn it. You wouldn't have thought the same if you had read it like s/Ruby/PHP/.

Fear not Atzanteol, Ruby is not a threat for you. This is your own [PHP] space and you're safe in it. Here, take your pill, and those zealots you see will go away.

Re:uh-oh

[MarkusQ]

it's still a million times better than PHP, which is just about the worst language in general use today

Can you explain in a few words why Ruby is so superior? Can you explain why PHP is worse than, for instance, Visual Basic, Fortran, or Cobol? If it's so obvious, it should be very easy to demonstrate.

A few words? How about one: taint.

Or for a broader one that incompasses the first, security.

These are just two examples of what I see as a broad pattern. The attitudes of the two languages (and their associated communities) are very different.

--MarkusQ

Re:uh-oh

[AaronBrethorst]

VB's a real object-oriented language. It's not perfect, no language is. Not C, PHP, VB, C#, Objective C, Ruby, or any of the others. But, it's come a long, long way since the days of VB 6. Ruby is incredibly cool, though, I have to say. I took the "learn a new language every year" idea to heart, and it's made me a far better developer for my trouble.

Re:uh-oh

[chriseyre2000]

There may be good reasons why someone is sticking with PHP.
I maintain a site in PHP (I am not about to slashdot myself). It was not my first choice for a language. I bought a cheap (£20 for two years - including 1GB transfer per month- can you show me a ruby hosting service that can match that?) domain plus hosting based on the availability of Python support. Unfortunately they had discontinued Python support shortly before that. I ended up using what was available (the choice was Perl or PHP).
PHP is not a great language but I have found that is fit for purpose for small sites (I make no claims for large sites having no experience in it).
However I have yet to find things that it can't do easily - PHP has been sufficient for my needs.

Re:uh-oh

[Atzanteol]

Wow, what arrogance. You assume that the OP has nothing better to do with his time than to learn your new pet language? Maybe he's married with three children and doesn't quite have the spare time like you seem to have? Perhaps he wants to keep the languages he learns to those that may be of use to him at his company (or future companies)? Maybe he doesn't pick up new languages as well as you do and it'll take much longer? Such an investment of time must be carefully made.

People without spare time needen't go learning every language just because *you* think it's nifty. I barely see any use of Ruby at all, and nearly nobody I work with even knows what it is. I have little reason to learn it. And If I had little spare time I would probably never think to pick it up until I start hearing about it at work.

How *dare* you assume to know what other people's time is worth?

The only Ruby-specific in my post is the suggestion to learn it. You wouldn't have thought the same if you had read it like s/Ruby/PHP/.

Fear not Atzanteol, Ruby is not a threat for you. This is your own [PHP] space and you're safe in it. Here, take your pill, and those zealots you see will go away.

Again, your arrogance shines... What makes you think I'm a PHP developer? Simply because I'm not ravenously pushing Ruby like crack? If so then I'm unlikely to ever become a Ruby dev. Sound like a bunch of born-agains. In fact, they're becoming almost as annoying as the Mac folks. Uh oh, you're not a Mac zealot too are you?

Question: I'm doing PHP work under Linux, can somebody suggest some books?
Answer from 500 morons: Get a Mac and do your stuff under Ruby!

Re:uh-oh

[kannibal_klown]

I'm all up for learning new things. Heck, I'm learning 2 things right now: 1 for work and 1 for home.

There is one problem though: if he works for a company, they may have very strict regulations about what he can/cannot use (for stuff at work).

For example, at my place we're pigeon-holed into using only a small set of languages and frameworks. They even recently cut back one or two.

The common reasoning is, if they don't put down controls, then developers go off and do their own thing, which is ok for the short-term. But then when someone else has to maintain it, they might not have the skillset.

So great, learn Ruby on your own! But his company might force him to use PHP and javascript.

Re:uh-oh

[mysticgoat]

This argument falls flat pretty quick. You don't need to abandon everything else you've learned to learn a new language.

I've got no argument about that. However the time you spend learning a new language I will spend in learning better approaches to the problems that I'm addressing with one language. That is, given a choice between spending half a day learning Ruby's syntax, and putting that time into tweaking a Perl object that models conversions between HTML and XML, I think I'm more productive by any measure continuing my work in Perl.

Not to mention that when I move between Perl, Javascript, and PHP I'm always losing some efficiency in stupid syntax errors, etc, as habits from the wrong language trip me up. These three languages are necessary and sufficient for me to do what I want (RWA stuff), so I can't escape some of these irksome problems. But I certainly don't need to compound them by learning Python.

Every language has advantages & disadvantages.

And every language has the means for working around its disadvantages as well as the capability of elegant expressions. (With the possible exceptions of Cobol and Mumps). There is something to be said for getting really good with a small assortment of tools as opposed to throwing every neat gadget you come across into your toolbox (and then having to spend the time maintaining your skills with all of them gadgets).

Remember, all four of these languages have the same underlying inspirations, so once you know one, it's much easier to learn another.

I know that every significant post-Perl language has drawn heavily on Perl. Perl itself is a distillation of many of the best language ideas that preceded it.

If you're a good PHP or Perl programmer, you can be a competent Ruby programmer in a week with some effort. Do you truly believe that your career & programming ability will be better served by NOT making that effort? If so, that's fine, that just leaves more jobs for the rest of us.

"Dear IT Manager:

I have been working on the kinds of problems that are central to your project for more than five years, coding predominantly in Perl. I understand the issues and concerns that you face. I recognize that you are a Ruby shop. I will be competent in Ruby by the time your HR department has completed my background and reference checks and we enter into the second round of interviews. Since a great deal of my skills in Perl will transfer to Ruby very easily, I will be one of your most experienced Ruby programmers before my three month probationary period is over.

I am very interested in the work that you are doing. Please schedule me for an initial interview as soon as possible. Thank you.

Sincerely,
mg

I think you'd better count on me and a bunch of guys like me as contenders for any job you are interested in.

Re:uh-oh

[ibbey]

I have never said that anyone should abandon PHP completely. I specifically state in another thread that a smart programmer chooses the right tool for the job. For small jobs, PHP will quite frequently be a better choice then Rails. But that's not because of any limitations in Rails, just that for small jobs the overhead of even a simple framework can be more bother then it's worth.

My point is not that everyone should switch to Rails. But learning a web framework is never a minor undertaking. For me, learning Rails has been much more difficult then it was to learn Ruby, and in my experience the same is true of every other framework I've looked at, regardless of the language. If you're investing that much time to begin with, you might as well consider -all- of your options, rather then limiting yourself based on a flawed premise.

Re:uh-oh

[f0rt0r]

Good point. A company thinks long term. Jim Bob wants to code a new solution in Ruby because its fun. What happens when Jim Bob leaves the company? Or transfers to another department. Omg, now John Bob has to learn Ruby and support it. 90% of the apps in the company are in Java and Jim Bob's manager approved Ruby.

Now his manager's manager wants to know what the business case was for coding in a langauge that:
1) No one else knows.
2) Could have been done in Java.
3) Offers no benefits over other languages already in-use in the company.
4) Has not been tested in the heterogenous company enviroments
5) Has no standards in place for system and user acceptance testing,

OK, he is sweating the decision he made to allow Jim Bob to use Ruby. Looks like he should have first come up with a business case for moving to it and made sure it passed the 'ritual of fire' before creating a solution in Ruby.

Re:uh-oh

[deadlinegrunt]

"Dunno "Active Record" from a hole in the ground, but I've had plenty of experience with packages that only take 3 lines to give you almost what 300 lines would otherwise do, and somewhere down the line you end up writing most of those other 297 lines to handle the edge cases."

::snicker::
Excellent point!

Re:uh-oh

[jsdcnet]

Ruby on Rails looks very interesting to me, yet I can't shake the nagging feeling that it isn't a good performer. Does anyone have any case studies? I'm in charge of sites with millions of visitors a day doing some pretty complex stuff. Optimization is our biggest challenge. I'd say we spend 90% of our time just trying to make things run faster.

Re:uh-oh

[Anonymous Coward]

Well stated.

Be proficient in problem solving and design.
The tools you use are just tools.

Personally, I code apps in ASM/C, and tools in PERL/Shell/C. People often ask me (aghast!) ASM? C?

How much Ruby runs on your microwave oven? How much Java is operating at the base level of your DSL modem? The deeply embedded world, a world often without an OS of any kind (no Linux??) is all around you. And so am I.

I play with other languages to see what may be useful in my toolbox, but I see no need to become proficient in a language that will never pay my bills.

If knowing that 'other' language becomes a part of my job, then I'll learn it (in three months) and be on my way.

Re:uh-oh

[smagruder]

Can you explain why PHP is worse than, for instance, Visual Basic, Fortran, or Cobol? If it's so obvious, it should be very easy to demonstrate.

It's not "worse". It's just that there's an inexplicable bias against PHP which has very little basis in reality. PHP is a great, powerful language that does what it does very well, despite its imperfections (and by the way, all programming languages have about the same degree of imperfections).

Re:uh-oh

[Anonymous Coward]

Shut up dumbass. I don't want to learn COBOL either. You lameasses hop from one programming language du jour to another, mastering none.

Re:uh-oh

[Khazunga]

A few words? How about one: taint.

Or for a broader one that incompasses the first, security.

The issues on that paper boil down to two problems:

1. register_globals must be turned *off*, which has been the default setting for some time
2. User input must not be trusted (must be validated)

The first is not a problem as of now, as the insecurity of automatically registering global variables with user input is a widely recognized problem. Any developer worth his salt will avoid register_globals (and it is off by default, I repeat).

Ruby's taint is *one* approach to the second problem, but it is not even the one I like best. I prefer design by contract, with precondition and postcondition checks in place. It clears up the 'juicy' code. After preconditions, you may trust user input, as it can't be tainted anymore. The actual processing code may be as simple as possible.

Re:uh-oh

[MarkusQ]

I prefer design by contract, with precondition and postcondition checks in place.

For what it's worth, Ruby supports both of those as well (e.g. with assert_* in :around methods, or in Rails with validates and/or before/after filters). I don't recall PHP having anything of the sort--or at least, I wasn't able to find it a few months ago when I was trying to shore up a badly compromised PHP application.

--MarkusQ

yet another framework

[larry bagina]

I haven't used it (I only learned about it from one of the endless /. RoR articles), but Cake is another option. If nothing else, the logo is making me hungry.

Which PHP5 Framework is Your Favorite?

[dont_think_twice]

Which PHP5 Framework is Your Favorite?

I guess I sorta like them all ...

Re:Which PHP5 Framework is Your Favorite?

[alatesystems]

Dude, I totally wish I could mod you up right now for that totally subtle Office Space reference. That made my morning.

+5, Awesome

Re:Which PHP5 Framework is Your Favorite?

[Safety Cap]

I feel the exact same way.... I celebrate the guy's entire catalogue.

not only that....

[Xtifr]

It's not like Ruby's a hard language if you already know Perl/PHP. I was able to pick up the basics in a couple of hours browsing. Now, if someone came out with, say, a functional scripting language, I might hesitate. I keep meaning to study Haskell or one of its cousins, but never find the time. But Ruby? That's about as straightforward as it gets!

Learn Ruby

[Anonymous Coward]

Listen, I've been programming PHP since version 3. I've been writing Perl since.. well since before some of you have been born. I've been working in Lisp and C since before that!

The secret to Ruby on Rails is RUBY. You just can't do that kind of stuff in PHP. PHP is pretty pathetic once you get beyond the basics. It is truly a language for the "bottom 95%" as I call it. PHP has at least the following flaws:

* poor metaprogramming: try creating an anonymous function in PHP, it's just a STRING! Yuck. Closures? Never heard of 'em. Try writing a one-liner in PHP that sorts a list of objects. Impossible.

* global variables for session, cookies, etc. Makes unit-testing a bitch!

* no "finally" clause on exceptions. WTF? Built-in functions don't raise exceptions. WTF?

* no way to refactor object fields. Yes you can use "__get/__set" but those "fake" fields don't work in every place a regular field works. WTF? In Ruby everything is a method, there are no fields, refactoring is a breeze.

* No "mixins".. I can't write a method and then stick it into multiple classes. Not even with include().

* Exposes variables vs. variable references. I thought PHP5 would get rid of "&" forever. I was wrong.

Now Ruby ain't Lisp, that's for sure. But I'd rather stick forks in my eyes than programming in PHP again.

Anyway, a good programmer has no problem learning a new language. It'll take you longer to learn the framework than the language. Ruby is simple and clean and VERY consistent from top to bottom, give it a try.

Re:Learn Ruby

[Bitsy Boffin]

THANK YOU MR COWARD!

That is the most coherent list of the deficiences in PHP compared to other more well designed OO languages that I have seen. Most people just say "oh PHP is rubbish compared to a real OO language" but they never bother to say exactly why they feel that way.

nobody can deny that PHP is a bit of a dogs breakfast when it comes to "design", it's had a very evolutionary and "throw everything in" history (a bajillion functions always there, no modularity), but the fact is that it works, it's not a great language but it does get the job done, and it is very popular because of the huge following and number of open source applications it has (bit of a catch-22 there).

What I find interesting is that Ruby has really started to take off, in the face of more established, and equally well designed languages such as Python (indented blocks not withstanding...ugh). One wonders if it's just the "ooh, new ad shiny" factor, or if Ruby is gonna be a force to be reckoned with for the long haul.

Certainly interesting times ahead, especially with PHP6 development beginning which sounds like it's just gonna bite the bullet and break compatability in order to fix the stupidities.

Re:Learn Ruby

[Khazunga]

All very beautiful. But then, why the heck don't you program in Smalltalk? Smalltalk has been here for ages, is the most beautiful OO language I've ever seen, and has all the features Ruby developers rave about.

The real question is: Does Ruby present the same flaws that prevented Smalltalk from taking over the world? Take a look to the side, and you'll find C powering most applications, not Objective C -- a much much cleaner language. This is the same kind of scenario.

Probably, a language for the bottom 95% is just what is needed. Why? Because of libraries. Where is the CPAN of Ruby? How does it compare to Perl's CPAN?

Delphi

[baadger]

Did anyone else click the PRADO link see TForm, TButton and TTextbox and just say to themselves "Delphi programmer"?

I don't have a point. I just thought it was kinda neat.

Re:Delphi

[namekuseijin]

yep, definetely a Borland brew.

Re:Delphi

[dolmen.fr]

Not me. I said to myself "Turbo Vision programmer".

not ruby specific

[namekuseijin]

it's not like i'm advocating ruby for any task whatsoever. i was just pointing out it was stupid to complain about learning a new language or tool. my example was ruby because the man cited RoR.

i could go with other languages like Python, OCaml, Scheme, Perl and many others, all with far better support for higher level programming, OO and modularization than that PHP crap.

Going right off topic here

[heinousjay]

Now, if someone came out with, say, a functional scripting language, I might hesitate.

You don't know Javascript? Or maybe you don't know that it has much in common with Lisp/Scheme, with C-like syntax? Look into it - as much as people denigrate it, it's one of the coolest languages out there.

Ruby has pretty much the same features - functional programming is very possible. If you master the concepts using these mostly familiar tools, it's much simpler to jump into the functional languages (or at least it was for me.)

Re:Going right off topic here

[Xtifr]

Nope, don't know the first thing about javascript. Outside my domain for the most part.

I do see that Ruby has functional aspects, but I don't have to use those for the basics--I can stick to the models I know, like OO. So its easy for me to get started. Eventually, yes, I suspect it will be as you say, but I'm not quite there yet. Still, I'm having fun, and that's the important thing. :)

Re:Going right off topic here

[Bitsy Boffin]

Indeed, Javascript is a very nice language. Prototypes rock. Now if somebody would come up with a nice shell binding for one of the mozilla JS engines, that would be cool.

Oy vey...

[Phleg]

Ruby on Rails looks pretty cool, but frankly, I don't want to learn a new language.

What a silly perspective. I've never met a carpenter who knew how to use a hammer, but refused to learn screwdrivers, miter saws, and a lathe.

Re:Oy vey...

[jaredshapiro]

I've never met a carpenter!

Zelots.

[Saeed al-Sahaf]

Why is it that there is very little PHP discussion here, and this story has been taken over by the RoR zelots? Seems like that's par here at Slashdot.

Re:Zelots.

[Anonymous Coward]

Because PHP sucks so much?

Re:Zelots.

[aminorex]

When a large number of intelligent people with practical experience conclude that a given tool is superior to another given tool, it's a good idea to check it out.

PHP is very accessible, and that's a great strength. But any time you start talking about "frameworks", you're well outside the user base that is best served by accessible.

Having said that, there are a lot of big PHP projects doing good service in the real world. It might not be the place to start new development, but integrating it into new development is going to be important for years to come. I'd be particularly interested to hear of good experiences integrating existing PHP apps with RoR development.

Re:Zelots.

[Anonymous Coward]

yes but it was stated he didnt want to learn Ruby.

for right or wrong that should have precluded any Ruby on Rails chat seeing as how the question was regarding Frameworks in PHP.

he didnt want to be convinced to try Ruby, he wanted a discussion about PHP

Frameworks for PHP, not that hot.

[Elamaton]

But with PHP5's, Object Oriented features, a standard framework might emerge.

Indeed, one might. So far, not looking so good on that front. All the frameworks I've encountered so far have seemed cumbersome or tedious somehow (I glanced at Prado just now; the advantages of their approach aren't readily apparent, I'd say. The demos are unimpressive, using some god-awful javascript: pseudo protocol links for updates and deletes, which really puts the internals of the framework into serious question).

It seems that PHP is bereft of any real, exciting developments on the framework front. There are a lot of frameworks, but I guess the reason why none stand out like Rails does with Ruby is simply that none are good enough, providing no significant added value.

You have to ask yourself: why a PHP framework? What such significant advantages would one of the existing frameworks provide that learning its ins and outs wouldn't be a waste of time and energy? If you're looking to automate some of the drudgework of form processing, for example, I suggest you roll a minimalist "frameworklet" - or simply "component" - yourself (if that's plausible in your situation) for that specific purpose, making it generic enough to be reusable, but not so generic that you end up fitting your projects to the tools instead of vice versa, which often happens with frameworks.

I've found minimalism to work really well with PHP. Frameworks that try to be all things to all people mostly end up being more trouble than they're worth. It may very well be faster and more efficient (and more fun) to code a small component for a specific purpose than trying to work with an existing solution. Your own solution will be tailored to fit your application and will work as your mind wants it to work, not the way the framework creator sees fit for himself.

It's a Unixy approach, I think: combine small tools in inventive ways to accomplish even the largest tasks. Of course, with tools of your own creation, you wouldn't have to deal with inconsistent APIs, a thousand syntaxes and wholly different philosophies across these tools. Write a custom session handler here, a generic input validator there... Even if you create these tools for a specific project, you will most likely find yourself reusing them in future projects, too, with possible minor customizations.

An example: when I first wanted a lightweight way of separating the business logic from the display logic for a project, I coded a single class that did the template stuff, using standard PHP with no additional burdens. Smarty etc. were readily available options, but PHP is already a templating language, and separate template engines would just have added excess bloat to the mix. My solution wasn't as feature-rich, of course, but it did exactly what it had to in the parameters set by the project specs. I've successfully and rapidly reused the code (and more importantly, the overall technique) in several later projects. Besides templating, I've had similar good experiences with an extensible input validation system I cooked up once, adjusting and refining it to later projects.

The way I see it is this: languages like Ruby and Python benefit from good web frameworks, since they're non-web-specific languages, and these frameworks make their use a lot more convenient in web programming. PHP, on the other hand, is very much a web programming language at heart. Ignore the "PHP suxx0rz!" trolls, it is a good tool for that purpose. (Even though it's capable of more, it's rarely - if ever - the best choice in those circumstances.) The best a framework would do with PHP is addressing clear shortcomings of the language in some way, but you don't really need a full-fledged framework to fight these annoyances. I find the "invented here" mini-component approach superior.

In short, I don't see a framework "enabling" significantly better ways to do web programming in PHP, unlike with Ruby or Python. For PHP, a framework will probably be more trouble than it

Re:Frameworks for PHP, not that hot.

[Qa1]

The way I see it is this: languages like Ruby and Python benefit from good web frameworks, since they're non-web-specific languages, and these frameworks make their use a lot more convenient in web programming. PHP, on the other hand, is very much a web programming language at heart.

I heartily disagree.

First of all, can you explain what's a good "web-specific-language"? As both a web-programmer and a general-purpose programmer, I'd say there's nothing really "web-specific" about a core language. You do need some good library support for stuff like handling web protocols (HTTP, url parsing, etc.), and both Python and Ruby (and many more) have that.

What's important in a core language in order to be suitable for web-programming is good string handling facilities. Which, when you look at it, is what "web-programming" is really all about: generation, manipulation, and occassionally parsing of strings.

I'm not sure how you can imply that Python and Ruby are not as good as PHP for web programming. You indicated that you're "looking to broaden my horizons a bit". So I guess you do know PHP well, but you don't really know Python or Ruby yet.

I've been a PHP programmer for years too. I worked in positions where it was just too problematic to switch. But eventually, I did, although it meant rewriting a lot of legacy code in a new langauge.

Why did I switch? Because I finally understood what I wrote in the above paragraph: that webprogramming is really all about generation, manipulation, and occassionally parsing of strings.

I've used Python a lot for general purpose programming, and I found myself over and over again unfavorably comparing PHP to Python when developing in PHP.

I would say to myself "o.k., now I need to get this substring from the incoming string, manipulate it a bit and plant it in the response page." And immediately a very short, concise and elegant solution Python would pop to my mind. But then I'd need to translate that elegant solution to some awkward PHP translation, and my mind would ache

To get the substring, I couldn't just do "substr = str[3:24].lower()" like I would do in Python. I had to use some godawful substr(str, 3, 24) function, and then run another function on the output, since PHP doesn't support the slice notation and treating of strings as objects that modern languages like Python and Ruby support as core feature.

Also, PHP's handling of regex (another important tool in the web-programmers toolbox) is coarse and awkward. Python's regex support is incomparably better, and Ruby's - even more so.

To sum up, I switched to Python from PHP4 since Python is, hands off, an incomparably better language for web-programming. And Ruby is even better than Python, which is why my current tool of choice is Ruby on Rails.

And while we're on the subject, why didn't PHP manage to create a framework as good as Rails, with all its huge advantage in user-base size?

That's because PHP isn't just an inferior language to Ruby in the web department (supposedly its home court) - its also generally a clunky programming language.

Writing a good web development framework is a general programming task. You need a good object system. PHP didn't even have a half-decent object system until release 5.0, and most of the world still uses PHP4. PHP doesn't have closures. It doesn't have elegant flow control mechanisms like Ruby has. It doesn't have any meta-programming facilities I'm aware of, while Ruby is the best meta-programming language I've used (with the possible exception of Lisp with its uber-macros).

So not only is PHP inferior to Python and Ruby for the simple tasks; for complex tasks, such writing a web-development-framework, the gap only widens. The result is that developing with a better language like Ruby, and on a superior platform like the RoR framework, is incomparably easier, faster, and more maintainable, even for the simple stuff PHP used t

Re:Frameworks for PHP, not that hot.

[Anonymous Coward]

That's all well and good, but Python and Ruby don't have decent Apache Modules. PHP does. Zope or Webrick can't scale. Not really. And you often need a middle layer between your HTML and your SQL. That's actually the *real* programming to some of us. Printing "Hello, $name", checking whether $fomr->name is 8 characters or less, or running $sql->execute($stmt) are the trivial parts of an application.

Re:Frameworks for PHP, not that hot.

[Qa1]

That's all well and good, but Python and Ruby don't have decent Apache Modules.

Sheer nonesense. Rails in a production environment is almost always used under Apach/fastcgi. Python has mod_python, on top of which Django runs (though I like that approach less than Rails').

As for scaling, both scale just fine, thank you. And several seasoned frameworks, like Zope, have scaling facilities that make mod_php look like a toy. I'm not saying mod_php doesn't scale; it does. But claiming it scales better than Rails or Zope is not just wrong; in fact, the opposite is true.

you win the horrible anaolgy of the day contest

[geoffspear]

I've never come across a carpenter who could drive nails, cut boards, and turn table legs with a hammer.

Re:you win the horrible anaolgy of the day contest

[bluGill]

Really? Come visit some time, I will introduce you do a few.

Carpenters do not use hammers for driving nails much anymore, their are tools that do the job faster. Take a hammer and beat a chunk of wood with the claw and you can get an acceptable dado. Not as good as what a chisel/dado saw/router can do, but acceptable for rough work, and you may not have the other tools.

I've never done it, but a sharp claw ought to be able to turn a table leg just like real lathe tools. Mind it would be very dangerous, but when you just need to get the job done and you don't have the tools...

Come to think of it, first year carpenters use their hammer more as a shovel than anything else. (how else to make a ladder sit level on a hillside?)

But none of this changes the fact there there are better tools for those jobs. If you need something quick, use the tool you have. If you spend a lot of time doing something, you should get the right tool for the job. Thus if you need a web page quick, and already know php, then use php. (though why you would know php I'm not sure...) If you are going to design a website, it is worth your while to get something better. Either Ruby or Python is better than php.

Which PHP App?

[ttfkam]

Isn't that like asking what type of sauce you want on your spaghetti (code)?

I have yet to see a PHP app -- especially one that also used MySQL -- that used a design pattern other than "Big Ball of Mud" most often.

Do be fair, PHP 5 looks pretty good -- or at least is a vast improvement. Unfortunately I can't say the same thing about the people who've coded in PHP up to this point. Even when PHP shows some growth, most PHP coders ignore it.

"Database abstraction? Why would anyone need that?"

"Namespaces? Why would anyone need that?"

"Design patterns? What are those?"

"Security? If it's a problem, we'll fix it later."

PHP: We'll be there for you if your development environment doesn't have enough side effects.

PHP: Because we know the money's in the maintenance contracts.

PHP: Because you obviously don't know any better.

PHP: We take security as seriously as Microsoft ten years ago.

PHP: Doing it fast is always better than doing it right.

PHP: Proving that if any idiot can write an e-commerce package, any idiot will.

PHP: Yet another great reason to make regular backups.

PHP: Fast, cheap, and robust. Two out of three ain't bad, right?

-----
I'm liking this meme. Anyone got any more?

Re:Which PHP App?

[Anonymous Coward]

Bullshit.

I know someone modded you funny, but its not. Its just a propogation of the same stereotypes.

I moves away from ASP several years ago into PHP. I would have made the switch earlier, but I had the same preconceived notions that you have -- that it was a language for amatures. Before ASP, I did straight C CGIs as well as dabbling in perl and AppleScript (I'm not sure which was less up to the task at the time...I still can't stand Perl for anything more than shell scripting and never understood how it took off for the web...but some people are very capable programmers even with a crappy language).

But since the time I moved over to PHP, my programming has gotted a LOT better. I stopped reinventing the wheel each and everytime I had a problem.

Everything is class oriented now instead of using pseudoclasses under ASP (dictionary objects and other hacks...and yeah, I know asp.net can deal with these, but I switched at a time that this wasn't an option nor was the lock in).

For once, I have the same ability to program that I did back in the C(++) days of compiled CGI apps without having to do 10x the programming (the speed was nice once, especially if the server allowed for caching the app).

And I'm still only using PHP4...5? I haven't seen anything in 5 thats got be thinking of switching yet. All the problems you complain about are things that ANY language has...and should be addressed by the programmer. For instance, security and otherwise can be taken care of by turning off globals and making the app strict. This should be done on any production server (unfortunately, most kiddie programmers can't afford a production AND a development server and thus these are turned off by default).

Its a simple language to program in and thus you have a lot of people with bad practices. Restrict programming to something that needs a lot more theoretical knowledge and you won't have this problem...you will also make things more difficult for those of us that can deal with the theoretical details and now how to avoid the problems.

At this point, I'm at the risk of making this a rant just like yours so I'll stop. All I know is that many languages have advantages others don't have and they all have their disadvantages...I'm happy with the advantage that I can do almost anything I want in PHP if the disadvantage is that it attracts a lot of idiots. I'm intrigued by the programmers that work with RoR but the language doesn't appeal to me any more than the hardcore database guys that love coldfusion (I had a developer working for me that begged to use this language until I had a major project to do and let him hang himself on it...the database part worked right, but the whole application side of things was a bust...I never had to hear him beg for coldfusion again...not a bad language, it just didn't do what I need -- and I need a good general language that is middle of the road in features but can be extensible to do 99% of what I need...and thats php).

Ok, the rant didn't stop where I wanted it to...

Re:Which PHP App?

[Mr. Slippery]

I have yet to see a PHP app -- especially one that also used MySQL -- that used a design pattern other than "Big Ball of Mud" most often.

You can remove the PHP qualifier from that statement and it's just as true. I've seen just as much good PHP code as good code in any other language - i.e., precious little.

Re:Which PHP App?

[ttfkam]

I moves away from ASP several years ago into PHP.

Sounds conspicuously similar to "I was coding in Prolog when I discovered BASIC."

For very simple pages, pages that amount to slightly more code than a server-side include, PHP is a perfect fit. This is obvious because PHP was originally made to be a page-embedded version of Perl -- originally written in Perl. Back in the days of CGI scripts, mostly in Perl, when you only had a little bit of code and a lot of markup, PHP (and ASP, ColdFusion, etc.) were a breath of fresh air.

However...

Embedding logic in your presentation layer is a bad idea. It ties your code to how your presenting it. Want to change how your site looks? Gotta change code. Want to change from HTML tables to CSS? Looks like it'll be a fundamental rewrite.

This is the problem that PHP -- and most mod_perl-based frameworks for that matter, like Slashdot -- have. It's a write-once language that you simply pile more and more code on until it breaks. Then you start over again.

I would have made the switch earlier, but I had the same preconceived notions that you have -- that it was a language for amatures. Before ASP, I did straight C CGIs as well as dabbling in perl and AppleScript (I'm not sure which was less up to the task at the time...I still can't stand Perl for anything more than shell scripting and never understood how it took off for the web...but some people are very capable programmers even with a crappy language).

We do not have the same preconceptions. We are coming from completely different points of view.

You: PHP is just as valid a programming environment -- if not more so -- as ASP, JSP, ColdFusion, and all the others for writing logic in web pages.

Me: Writing logic in your presentation layer (your web pages) is a bad idea no matter what language you use.

See the difference?

But since the time I moved over to PHP, my programming has gotted a LOT better. I stopped reinventing the wheel each and everytime I had a problem.

Of course you have. Usually the more you do something, the better you get at it. But I'm not suggesting that you drop PHP for something like JSP. I'm suggesting that they both suck as web development models. PHP is simply the newest kid on the block to support this crappy development model.

Everything is class oriented now instead of using pseudoclasses under ASP (dictionary objects and other hacks...and yeah, I know asp.net can deal with these, but I switched at a time that this wasn't an option nor was the lock in).

But ASP had CreateObject to instantiate any scriptable COM object registered with the system. ASP was meant to be a logic linking framework, not the logic itself. In other words, the code that did the heavy lifting was not supposed to be the Visual Basic Script; it was supposed to be your COM objects -- written in a more powerful language.

People are writing the "heavy lifting" code in PHP. This design pattern is known as "Big Ball of Mud." You may be getting better at giving it form, but it's still a ball of mud.

For once, I have the same ability to program that I did back in the C(++) days of compiled CGI apps without having to do 10x the programming (the speed was nice once, especially if the server allowed for caching the app).

So in other words, you are doing today what you did ten years ago, only faster -- neither cleaner nor more secure.

Incidentally, speeds for process invocation and forking on many platforms has increased dramatically. Those old CGI scripts in C and C++ would run faster even on the same hardware, eg. running the same code on Linux 2.0.x versus 2.6.x.

And I'm still only using PHP4...5? I haven't seen anything in 5 thats got be thinking of switching yet. All the problems you complain about are things that ANY language has...a

Re:Which PHP App?

[ttfkam]

Fair enough. :)

Re:Which PHP App?

[tom's a-cold]

Me: Writing logic in your presentation layer (your web pages) is a bad idea no matter what language you use.

While I agree with this, I think that, for trivial apps, it's not such a big deal to mix the presentation layer and the logic. The problem I have with PHP is that some over-enthusiastic developers have tried to extend its use to writing enterprise applications. That's not what it was designed for, though feature-creep has moved it a little in that direction. There's not much wrong with it for small-scale throwaway web apps, but beyond a certain point, it just isn't the right tool anymore.

I saw some earlier posts that were sneering at language features that "95% of us don't use." Well, that might become what keeps you from being one of the 5% who will still be programming five years from now. Though I've met a few diehards who were writing spaghetti ten years ago and still are.
And, just to be very clear, I'm not a language zealot. I have coded in, and led teams who coded in, C, C++, Java, Smalltalk, Lisp (various flavors), Perl, Python, Ruby and various app development frameworks. Despite my having used other languages, and the likelihood I will continue to do so, I understand what drove the additional features in Python and Ruby and enjoy the added productivity that they enable. PHP was meant more to "get the job done, screw the fancy stuff" and the simplistic feature set has become a limitation as its usage has grown.

Re:Which PHP App?

[Anonymous Coward]

Agreed. Just like the developers of PHP think that not including legacy VB/ASP's "option explicit" or Perl's strict mode is a good design choice.

Re:Which PHP App?

[JonasH]

PHP will spew a notice if you use an unitialized variable. Whether or not that's good enough is debatable, but it's better than nothing at least.

Of course, notices aren't shown by default (presumably because it'd wreck havoc on most pieces of php code) so most people won't know. First thing I do to my php.ini is to set error_reporting to E_ALL (default is E_ALL & ~E_NOTICE it seems).

Re:Which PHP App?

[Bitsy Boffin]

I didn't read your whole post, becaue I'm inherently lazy, but this statement...

Embedding logic in your presentation layer is a bad idea. It ties your code to how your presenting it. Want to change how your site looks? Gotta change code. Want to change from HTML tables to CSS? Looks like it'll be a fundamental rewrite.

This is the problem that PHP -- and most mod_perl-based frameworks for that matter, like Slashdot -- have. It's a write-once language that you simply pile more and more code on until it breaks. Then you start over again.

I agree that embedding business logic in your html is a bad idea, but PHP IS a templating language. I see no problem with

<?php echo $somevar ?>

rather than your typical template language's

{somevar}

or

<?php foreach($record in $records) { ?> <tr>....</tr> <?php } ?>

instead of

{loop $records} <tr>...</tr> {/loop}

(or whatever your chosen template language syntax for looping is).

Separate the _business_logic_ from the _display_logic_, and you'l be just fine and write maintainable views in PHP.

Re:Which PHP App?

[Anonymous Coward]

Again, you really don't know what you are talking about.

You are confusing PHP with any language that a novice might write in.

Abstracting logic with presentation? Only an idiot does this. This is one of the great things about the language -- you can mix the two if you are a bad programmer, and really bad programmers don't even know how to think past the fact that its possible to do this -- and it doesn't care.

Seriously -- design with a decent OO oriented structure and you will not have any worries. It took me all of a day to change my last PHP app to utilizing CSS. It would have taken me much longer if we were taking static web pages. The ASP running on the same server (from a much earlier project that we haven't been able to get back and rewrite) took a bit longer because there was a LOT of mixing presentation with logic. Again, these things happen because of experience. Working in ASP, when I have to, these problems don't happen today.

And as for: mysql_query('SELECT foo FROM bar WHERE id = $id')

Seriously? You'd pass a variable into a SQL command? Without doing any preprocessing? You'd even think that this was possible? Until you just posted this, I completely forgot some idiots think this way.

Me -- I don't want *ANY* programming language editing the variable I'm throwing at a specific function. If I ask it to throw $id='1; DELETE * FROM BAR;' into the SQL Query, I don't want the application editing my query.

Then again, thats what stored proceedures with specific rights given to each are designed for. My programming language worries about the security of the program and my sql app worries about the security of the SQL statements.

But *ANYONE* even thinking in such a way that they'd allow their SQL statement to pass variables along like this is an idiot. Anyone that thinks a programming language should be holding your dick when you are programming statements like this is, too, and idiot.

As for globals and 'other lameness' -- again, you show how little you actually know about programming. I guess the whole idea of Constants is also bad because someone might get into one of your files and edit it where it effects the entire program. And that you do nothing to make certain that these variables are nondestructive in the context of your application simple because they say they are what they say they are. Thats just plain bad programming. Of course you can't fucking trust whats posted to you...but at the same time, there isn't anything wrong with accepting them and automatically reproces them yourself. Thats the FIRST thing that happens with any query data that comes into my system -- I save the original query string to another location intact and then replace the old with safe strings. Again, this is something the application developer should be doing NOT THE LANGUAGE. I have reasons I keep the unaltered strings intact -- I may need them exactly as they say they are.

As for 'Big. Ball. Mud.' Congrats. You learned a new phrase and are trying to use it correctly. You have failed, but you get a gold star for the effort. You cannot even think outside of your little world and understand how this can be done.

I miss the days when I was a know it all programmer that thought I was right and everyone else was wrong. Now these days, I realize the only people I know more than are the dumb fucks that post to Slashdot professing to be experts when they are just parroting an opinion they read on some website. Thanks for reminding me why I grew up.

Re:Which PHP App?

[Anonymous Coward]

You are confusing PHP with any language that a novice might write in.

And you are confusing PHP for a language that wasn't written with beginners in mind.

Abstracting logic with presentation? Only an idiot does this.

Or a beginner.

And as for: mysql_query('SELECT foo FROM bar WHERE id = $id')

Seriously? You'd pass a variable into a SQL command? Without doing any preprocessing? You'd even think that this was possible? Until you just posted this, I completely forgot some idiots think this way.

Beginners do. Also remember that for most of PHP's existence:

1. prepared statements weren't an option
2. most PHP developers used MySQL exclusively, which until recently did not have support for stored procedures

Me -- I don't want *ANY* programming language editing the variable I'm throwing at a specific function.

You're absolutely right. No one who realizes what an SQL injection attack is and what it can do would want that. This is why prepared SQL statements should have been in the database libraries from day one. They weren't. They weren't even in year one. Or two. Or three.

It's commonly referred to by the phrases "bad design" and "lack of forethought".

My programming language worries about the security of the program and my sql app worries about the security of the SQL statements.

Then why did PHP introduce "register globals"? Why is it still there? Guess what? Your programming language isn't worried about the security of the program. I'm betting you've never even seen the Zope (python) access control tools (built into the framework) or the Java policy manager (built into the language). If you had, you wouldn't be using the words "PHP" and "security" in the same affirmative sentence.

But *ANYONE* even thinking in such a way that they'd allow their SQL statement to pass variables along like this is an idiot. Anyone that thinks a programming language should be holding your dick when you are programming statements like this is, too, and idiot.

Beginners are not idiots. They're beginners. As for my programming prowess, I'm not quite sure you want to get into a pissing contest with me.

And besides, if you don't want your programming language to "hold your dick when you are programming statements like this," why are you using PHP? PHP is all about automatic memory management, easy string manipulation, a ready-to-use standard library, etc. If you're going to get into a "who's got the bigger programming dick" contest, stop beating around the bush and just write some Apache modules in C. Oh, that's right. Getting help from the language is okay as long as it makes an arbitrary decision as to what it will or will not help you with.

Yeah, that makes sense.

Now these days, I realize the only people I know more than are the dumb fucks that post to Slashdot professing to be experts when they are just parroting an opinion they read on some website.

Now that's comedy. I've never heard anyone actually defend register globals. That's a new one for me. Congratulations.

As for parroting opinions, you will forgive me if I say that I'm the one that writes opinions on websites for others to read. And my opinions are based upon personal experience, not punditry.

What? You assumed that I hadn't used PHP professionally before? That's a shame. Only goes to show what happens when you assume.

Re:Which PHP App?

[Anonymous Coward]

I don't think I ever said you weren't a good programmer.

I know a lot of great programmers that are idiots and don't think about anything past the theoretical. That goes for commercial programmers as well.

Most of the guys working for me are FAR better programmers than me. At the same time, they have no common sense and can't get anything done because they either factor the problem to the bare minimum of the specs and wonders why the client doesn't like it (generally it never gets to the client because my job is to make certain things are spit and polished for the client).

As for writing an apache module, sorry...I had the heartbreak of having to deal with this crap back in the day. I wrote a few modules for WebStar back in the day. That was enough hassle and it wasn't half as complicated as Apache. As I say, I'm not the greatest programmer, but I do have common sense lacking in most of your kind.

Re:Which PHP App?

[Anonymous Coward]

*whoosh!*

That was the sound of a point going right over someone's head.

You brag about adding the "spit and polish" that your programming staff fails to see the value in. And by the way, I whole-heartedly agree with your role. Truth be told, I am a big advocate for UI engineering and usability in general.

However from a purely *practical* point of view, I find "your kind", the kind that focuses on the immediate sale -- however important that role may be -- tend to downplay security concerns while applying their "spit and polish".

I wish your condescending ass well.

Re:Which PHP App?

[Kosgrove]

I'm aware that the cost of the platform just to develop is quite high, but Micosoft really got it right with ASP.MET:

There is very rarely a reason to mix scripting code and HTML in the web page itself - all programmatic stuff goes in what they call a "code-behind" file which is straight VB.NET class which imports (like a #include) the system.web namespace. Are there any other languages/plaforms that have such a feature? (I'm asking because I'd genuinely like to learn about them.)

It just makes everything so much more readable.

Re:Which PHP App?

[Anonymous Coward]

I've never focused on the sale.

In fact, if the app isn't ready, it doesn't leave my server.

The thing is, you complain about security as if its something that is unaccomplishable and that only the greatest of programmers can do it. It takes very little to secure a PHP app, many items I listed earlier. It doesn't take a genius programmer nor does it take an arrogant geek that couldn't social engineer his way out of a paper sack.

I think the big whoosh was you not realizing that your kind is a dinosaur because there are others that aren't as skilled but can deliver anything you can without all the fancy programming or new pseudointellectual language, and still have the same amount of security without having to pretend that you are the only one with the knowledge.

UI is my main concern. Its what I did my grad research on. I know that I know more about this than my programmers, but at the same time I don't expect them to know everything I do...I do expect them to TRY to get past just the pure specs or deliver something that is useful to someone that isn't them. So spit and polish is my main goal...its just the other stuff is so easy to accomplish with just a little attention that I don't know why some people make it a big point.

Re:Which PHP App?

[Anonymous Coward]

Security is not a lightswitch that you can turn on or off.

It's an arms race.

Re:Which PHP App?

[TheTomcat]

"Database abstraction? Why would anyone need that?"
http://php.net/pdo

"Namespaces? Why would anyone need that?"
it's coming

"Design patterns? What are those?"
http://php.net/language.oop5.patterns
http://phppatterns.com
php|architect's Guide to PHP Design Patterns

"Security? If it's a problem, we'll fix it later."
http://php.net/security
(Almost all of PHP's historical security problems have been third-party.)

S

Re:Which PHP App?

[dolmen.fr]

I have yet to see a PHP app -- especially one that also used MySQL -- that used a design pattern other than "Big Ball of Mud" most often.

Have a look to the Drupal code. Great innovative design can be found there.

Re:Which PHP App?

[ttfkam]

"Database abstraction? Why would anyone need that?"
http://php.net/pdo

From the top of that PDO page you sent me to:

Warning

This extension is EXPERIMENTAL. The behaviour of this extension -- including the names of its functions and anything else documented about this extension -- may change without notice in a future release of PHP. Use this extension at your own risk.

Re: namespaces. How old is PHP? And they're only now getting around to it? Younger languages seem to have them. Why has PHP, a very popular language with an active community, taken so long to implement them if for no other reason than they didn't think it was that important.

Re: design patterns. I see that those have come around since PHP5 was released, now that it has real objects. I also notice that there have been a lot of comments from PHP developers that PHP4 was sufficient, and they saw no need to switch. Wake me when PHP design patterns become relevant, ie. are widely adopted.

As for security... *sigh* From the page you linked:

For real security you should consider providing chrooted jail's for your users.

Good advice, no matter what the product or language. Next quote:

Remember that security risks often don't involve months of prep work or backdoors or whatever else you saw on Swordfish ;) In fact one of the bigges newbie mistakes is not removing "<" from user input (especially when using message boards) so in theory a user could secerely mess up a page or even have your server run php scripts which would allow them to wreak havoc on your site.

And here we have a failure of the model. This is yet another classic example why logic should not be embedded in your presentation layer.

best bet is to build php as cgi, run under suexec, with chroot jailed users. Not the best, but fairly unobtrusive, provides several levels of checkpoints, and has only the detriment of being, well, kinda slow. 8)

"Kinda slow" being an understatement. "Kinda slow" guarantees that most PHP users will never use a chroot environment. So we're back to square one.

If your PHP pages include() or require() files that live within the web server document root, for example library files in the same directory as the PHP pages, you must account for the possibility that attackers may call those library files directly.

Any program level code in the library files (ie code not part of function definitions) will be directly executable by the caller outside of the scope of the intended calling sequence. An attacker may be able to leverage this ability to cause unintended effects.

The most robust way to guard against this possibility is to prevent your webserver from calling the library scripts directly, either by moving them out of the document root, or by putting them in a folder configured to refuse web server access. With Apache for example, create a .htaccess file in the library script folder with these directives:

Order Allow,Deny
Deny from any

And beginners are equipped to follow -- or even understand -- that last requirement. It's a shame there isn't a policy manager or programmatic sandbox for the code. That would tighten security by default. But wait. I forgot. It will restrict people's programmatic freedom of expression or some such nonsense.

Here is the point that a lot of folks don't seem to get. It is possible to code assembly robustly, securely, and extensibly. However, it is extremely difficult to do so for any non-trivial apps. If more than 75% of PHP coders do not understand what is necessary to secure their environment, I blame the language, not the coders.

Take an example from Java applets -- not the language, the VM in general, or any real or perceived speed problem

I know which one

[Anonymous Coward]

Use that one that makes it dead-simple for some asshole to come and hack your web site (c.f. avrfreaks.net two weeks ago). That way I will clean up in the consulting fees telling you why you shouldn't use PHP.

Does PHP5 suffer from excessive RAM usage?

[CyricZ]

I read a post a few days back regarding PHP5's supposed excessive use of memory:

http://books.slashdot.org/comments.pl?sid=158685&c id=13297391

Now, I have been contemplating the use of PHP5 for various webapps, but after reading that I am unsure about whether or not I should use it. Mind you I do not want to invest large sums of money into an accelerator, which appears to be necessary if reasonable server memory usage is a goal.

Does PHP5 indeed suffer from excessive memory consumption, and if so, can it be easily remedied? Considering I have a low-end server hosting several fairly busy personal sites, minimal memory usage is extremely important.

Re:Does PHP5 suffer from excessive RAM usage?

[seek31337]

PHP does use a significant amount of RAM, but this is largely based upon what modules you are loading in. If you're writing basic SQL query pages with some crypto, then just load those modules. You'll still use some memory, but much less that loading GD every time, and not using it. You can also install the modules and call them only when you need them.

The Apache module does use a significant amount of RAM, but unlike standard CGI's, the processes are not dying and re-spawning, so the same process actually processes many pages before re-starting, so there is not a big problem except when you have scripts processing at the exact same time on the server. With CGI's, you get a lot more memory thrasshing. For Perl, Python, etc, there are apache modules that do the same kind of thing, but I have no experience with them.

Accelerators help you in that the process will complete quicker, thus there's less overlap of processing. A great free accelerator is eAccelerator (http://sourceforge.net/projects/eaccelerator/). Their main site appears to be down right this second, and it's flagged as 'beta', but I have been using it without any problems. Granted, we are pre-production, so I have not tested it under a lot of load. I put up a cop of their 'README' on my site at http://under-score.net/~brian/eaccelerator.README. txt

I use...

[Karaman]

gtk.php.net

version 2 will work with gtk 2.x, which is great!

It is not much of a thing, but will be ok!

eGroupWare, of course!

[mangu]

I was assigned a task that would seem to be more or less the dream of any programmer: develop a QA management system (ISO9001 compliant, of course) for the whole company. Choose freely how you want to do it.

After searching all over for several weeks, I chose eGroupWare. Their "etemplates" framework settled the issue for me.

Re:eGroupWare, of course!

[Seumas]

I was assigned a task that would seem to be more or less the dream of any programmer:develop a QA management system (ISO9001 compliant, of course) for the whole company.

This completely explodified my sarcasmification detector . . .

Hammer + tool

[loadquo]

You could theoretically cut boards and craft table legs with a hammer + chisel. Doesn't mean they would be nice or pretty, but it is theoretically possible

Ruby is a passing fad, a PhD's toy

[mangu]

Your arguments remind me of a professor I once had, trying to tell me how Modula2 was so much better than C/C++, which he called "medium level" languages.

Yes, sure, if you worry about "metaprogramming", "refactor object fields", or "Exposes variables vs. variable references", then Ruby is the language for you, but... how about Oberon? Now that's one language I'm sure you'll love!

OTOH, if you aren't in an ivory tower and have to program for a living, then PHP is like C, a language the "perfessors" hate,but it keeps working just fine for the 99.5% of us.

Re:Ruby is a passing fad, a PhD's toy

[ttfkam]

OTOH, if you aren't in an ivory tower and have to program for a living, then PHP is like C, a language the "perfessors" hate,but it keeps working just fine for the 99.5% of us.

Would that be the 99.5% of all C apps that have weekly buffer overflow exploit notices?

Or would that be the 99.5% of PHP apps that have constant SQL and variable injection attacks. *cough* PHP XML_RPC support *cough*

Re:Ruby is a passing fad, a PhD's toy

[Unordained]

Err ... yes. Most languages get used both carefully and not. Even the best keep-you-from-shooting-yourself-in-the-foot languages won't prevent you from writing incorrect programs; I'm really not sure why people bother. Buffer overflows aren't hard to prevent, and if a programmer gets caught writing one once, will probably never do so again. SQL injection is an issue in any language because people insist (note, I do this too) on writing their SQL as strings and injecting values into those strings, as opposed to using prepared statements with placeholders (which is much safer, but I'm not sure all API's support it.) It's a matter of using libraries correctly. But hey, let's complain about divide-by-zero errors and blame the language rather than the programmer.

Buffer overflows and SQL injection can be prevented, if you just learn a little bit. Those responsible are either chronically irresponsible and shouldn't be coding at all, or haven't learned enough yet, and should be taught. Irresponsibility and ignorance aren't language issues, they're people issues. Language choice is much more about preference/habit/comfort than language features or available libraries.

Re:Ruby is a passing fad, a PhD's toy

[ibbey]

There's a reason that Ruby programmers are such annoying cheerleaders-- the language is genuinely fun. Add to that the facts that you get much more done in much less time and your code is inherently less buggy, and you begin to see the reason for our enthusiasm. I challenge you to pick up Programming Ruby (or the new Agile Web Development in Rails). You may not decide to switch but you'll understand why we have.

The need to learn a new language is certainly a reasonable concern. Fortunately Ruby has a reasonably shallow learning curve. Coupled with the boost in productivity you'll get from using Rails, you will likely make up the downtime lost to learning on your first sizeable job.

Re:Ruby is a passing fad, a PhD's toy

[CatGrep]

Yup, dag nab it! Them Ruby college boys keep come'n round here'n tell'n me that I need to learn their language, but I'll stick with my COBOL thank ya very much!

Re:Ruby is a passing fad, a PhD's toy

[Colonel Panic]

Yup, it's way too hard for you. Best stick with PHP.

(while the rest of us program rings around you in languages like Ruby, Python and Lisp)

Frameworks create as many problems as they solve

[Anonymous Coward]

Creating my own framework was one of the first things I did in PHP, it's currently on it's 4th incarnation since it went live in 2001 and powers several commercial sites. The final revision was a possibly premature conversion to PHP5 that I begun last October.

The majority of web frameworks I have looked at consist of wrapper code to instantiate classes and other pointless indirections. It's as if somewhere along the way the authors begin writing code for the sake of it, constructing these hugely complex systems that offer no real world benefit over writing a simple procedural script. For example, creating classes to produce html elements that require more work to create than just hand typing the html is a pointless waste of time.

PHP really isn't the greatest language to write anything but the simplest of frameworks in and the performance of the current (PHP5) engine is terrible (APC still doesn't support the new object model). PHP6 will essentially be PHP5.1 + unicode which is the deciding factor for me... I'm moving on from PHP and away from web frameworks, although I will continue to laugh at the anal buzzwords used by their proponents to justify them.

I'm considering rewriting our webapps in ruby. I'm also about ready to punch the next person who mentions "rubyonrails" in my vacinity.

Ruby resources

[Santana]

Heh, well, no offense but, people that use to reply like you haven't tried Ruby, or don't understand it. Otherwise you would be in love with it already.

We cannot compare PHP and Ruby. It's like comparing BASIC and Perl, you get the idea. Remember when you discovered Perl and all its magic? Well, that's what happens when you get into Ruby. It's a true object oriented and dynamic language ready for real applications.

This might or not make sense to you. It depends on the use you are giving to your language of choice. If you write one-liners in Perl, you might not feel motivated to move to Ruby. If you are writing templates in PHP for your web applications and you're doing fine, you might not need Ruby either.

You see the light :) when you want to write OO applications/scripts. PHP used to have an awful hack (I haven't seen PHP 5), so does Perl 5. Python would be your choice, but for some reasons I cannot explain (yes, this is subjective) Ruby feels more natural.

Ok, I have fallen again in the "I love Ruby so much" that gets you so bored. So, here is some homework for you (some very nice presentations and small articles):

Ruby: A transparent, object-oriented programming language
10 Things Every Java Programmer Should Know About Ruby
The Ruby Programming Language (by Matz, Ruby's author)
Thirty-seven reasons I love Ruby
Blocks and closures in Ruby

A Short History of Web Apps

[ttfkam]

In the beginning, you had files and web servers. Then people starting writing extensions to the web servers and the dynamic web was born.

But the problems with patching your web server for even the slightest dynamism were immediately obvious even in the early days of "a patchy server". So CGI (Common Gateway Interface) was born and Perl rose up as the dominant web language. Process creation overhead became an issue as the web took off so techniques for mitigating this were put in like mod_perl, servlets, etc., but overall the process stayed the same.

People started learning, slowly, that the internet wasn't a nice place. Maliciously altering query string variables to affect server processing or inject SQL code started to become commonplace. Libraries that urldecoded query strings and database libraries that used prepared statements to prevent (basically eliminate) SQL injection attacks made the rounds.

While an improvement over what came before and most definitely useful, embedding markup was an absolute pain. All sorts of hacks rose up to programmatically write markup. But then a lot of people noticed at the same time that a lot of their dynamic pages were mostly static markup with only a token amount of logic. Thus the age of ASP, PHP, JSP, ColdFusion, et al. was born, and it was cool runnings for a while. If you needed a lot of logic, you wrote code with a markup generation library. If you only needed a little logic, you wrote a markup file with code markers for logic.

Things started going south when people with no programming experience started learning from those ASP, PHP, and JSP examples. They gleefully added huge tracts of code in these files, giving new life to a much maligned design pattern known as "Big Ball of Mud". Soon everyone starting getting stuck in the ever-growing balls of mud. Simplify! Encapsulate! Componentize!

We'll just add new markup. We'll call them "tag libraries" and put all the code snippets into these markup fragments. Brilliant! Now the people who don't know how to program can just write markup and coders can write stuff further up the chain.

Further adding insult to injury, PHP completely ignored the security lessons of the preceding years and allowed arbitrary variables to be set from the browser URL and completely ignored not only database abstraction facilities in the language in which it was originally written, Perl and it's DBI, but the entire concept of a prepared database statement.

JSP and its ilk were born just before this point, tag libraries and embedded Java in all their splendor, enforcing markup well-formedness and driving popular usage.

People still wrote logic in their markup though. And even the tag libraries became more and more monstrous. A tag library for databases. A tag library for data formatting. A tag library to make more tags. A tag library to perform backend workflow. A tag library to do the laundry and wash the dishes.

Meanwhile, academic gadflies coined the acronym MVC (Model-View-Controller) and starting going on about something called SoC (Separation of Concerns). Everything started going gonzo at that point.

HTML was no longer supposed to have styling info; that is now CSS's job. Our data repositories may change -- and may or may not be relational databases anymore. Hard-coding database connection strings, table names and column names is frowned upon.

URIs were also full of .asp, .php, .pl, and other extensions that didn't describe the content returned, but how the content was generated. Switching or upgrading technologies often meant creating large numbers of redirections -- commonly with the king of web voodoo, mod_rewrite -- at best, breaking links on your and other sites at worst (and more likely).

Enter the sitemap. Have the framework handle the URI space. Now your site can become technology-agnostic. As an added benefit, those framework authors also added processing pipelines where a given U

Time for a new Netcraft report...

[Anonymous Coward]

Netcraft confirms: Ruby is dying

People vs. Technology

[ttfkam]

Except that for years PHP and MySQL, tools marketed to beginners, didn't have the "correct" option available.

And beginners won't know to ask about it. The incorrect option is all they know. The solution, of course, is better tools. ...and tutorials. There is no excuse as a documentation/tutorial author to demonstrate values injected into SQL strings in examples.

And, once again, there is NO excuse for building a network-aware technology that allows for setting variables from the URI query string. None. Even PHP's predecessors had better sense. It speaks volumes that after it was exposed as the security nightmare that it was, it was simply disabled as opposed to removing it outright. Why? Because it would break existing apps? Guess what? Apps that blindly allow end-user manipulation of variables are already broken.

The correct decision is fixing the flaw, not merely disabling the flaw by default. It should not be an option. If developer need that functionality for some corner-case reason, they should be knowledgeable enough to write the functionality themselves.

That, in a nutshell, is why I don't like PHP. It doesn't present good decision and allow people to make bad decisions, it presents bad decisions by default unless developers write the better behavior themselves -- better decisions that newbies, by definition, will not make.

Re:People vs. Technology

[stonecypher]

Except that for years PHP and MySQL, tools marketed to beginners, didn't have the "correct" option available.

And beginners won't know to ask about it.

Eh. There's no way to give amateur developers the ability to produce professional code. If you want a secure system, don't hire a novice. It's not PHP's fault that a developer is a failure, to be quite blunt.

And, once again, there is NO excuse for building a network-aware technology that allows for setting variables from the URI query string. None. Even PHP's predecessors had better sense.

Actually, in PHP and PHP/FI days, that was common practice, and in some languages still is.

Re:People vs. Technology

[ttfkam]

Actually, in PHP and PHP/FI days, that was common practice, and in some languages still is.

I meant predecessors like Perl. As for common practice, not in any circles I've been exposed to. Even C tutorials from twenty years ago for command line apps preach distrust and validation of user input as standard procedure.

In the modern internet, the practice is unforgivable.

Re:People vs. Technology

[stonecypher]

Oh, I'm certainly not defending the problem; you're quite right to suggest what an issue it is. I just tend to believe that the problem comes from the programmers, rather than the language.

Re:Hi, please shove it up your ass

[Anonymous Coward]

Jesus people are getting extremely annoying these days. Every time any sort of scripture language is mentioned, you're all compelled to tell us why Jesus is better. You know what? We've heard enough of your cheerleading.

Have your cake...

[Hallow]

Oh, uh, yeah, how about cake? It's a rails knockoff for php.

MVC Framework

[antigravity]

http://www.mojavi.org/ Check the forums for many open source example sites.

Your own DBMS

[systems]

Okay, I admit the analogy is a bit extreme but it makes the points obvious.

The thing is I think people don't think deep enough anymore.
What is a framework?
I not sure we can all agree on the answer, I am sure that there is a formal answer.
I would say a framework, is a factory.
Someone else can say, a framework is a meta-tool, a tool that makes tools.
Another can say, a framework is a domain-specific language.
And another (the one I like the best) would ask, what is the difference between all those answers.
Does C++ or Haskell, qualify as frameworks, why and why not?
Does PostgreSql qualify as a framework? why not, couldn't we say that pgsql is a framework to create databases, it just happens to implement that standard language called Sql.

The point I want to make is, a framework is software that helps you tell the computer what you want to do, in that I don't see how can a framework be any differant than any software you've used (thinking about it I can say MS Word is a framework to create documents). So disregarding frameworks altogether is just wrong.

A framework will include the know-how of some developers, you should not start from scratch, you should not start from the beginning, you should always start from where others have ended, to learn from their work and experience, else have other have said it before me, you are deemed to reinvent the wheel, and you will be pushing your self back to the stone age (or whenever they actually reinvented the wheel)

frameworks? no i18n, no custom auth, ...

[HTD]

Almost all the frameworks, no matter which language they are written in, don't provide the basics for a real world application. What about i18n? I have yet to see a framework where the template system AND the application supports translation of messages.

Customize Authentication? There are more complex apps that don't just require username+password to login (e.g. logon to database - username+password+database depending on the database you may have access or not). Also users may be in many groups, each group having different rights, even each user could have different rights - where the next isssue comes up.

Only few socalled frameworks have rights-management. There are actions that should be restricted to qualified users, like editing customer-accounts, adding new co-workers. There are things that should be displayed only to certain users. Think of current items in-stock of an online-shop. You probably want to show the shops co-workers the real in-stock amount and some info when the next delivery of that stuff is coming and the customers would see in-stock minus 10% and no info on the upcoming delivery - from the same template, only difference is the rights the user has.

These are just 3 examples of missing functionality that keep me from even considering any of those "frameworks".

Re:frameworks? no i18n, no custom auth, ...

[Anonymous Coward]

Doesn't the Horde project allow for all of the things you mentioned?

Re:Frameworks create as many problems as they solv

[Anonymous Coward]

PHP6 will essentially be PHP5.1 + unicode which is the deciding factor for me..

What?

php.MVC

[slopedome]

Try this:
http://www.phpmvc.net/

It's in beta, but I think a good MVC framework is all PHP needs to stop looking like such spaghetti. In defense of the Ruby zealots: I've haven't learned Ruby yet, but it's exactly the futuristic *REAL* object-oriented language that's going to propel us into the future. PHP is very old-school in the way code is written -- it DOES encourage spaghetti coding -- and for that I think it deserves to be phased out.

Can this discussion ever happen without...

[Anonymous Coward]

...the idiotic "OMG PHP is teh sux0rz [ruby|perl|ada95|..]==l33t". Let's just assume that we all know some people hold that opinion (about any language), and if you promise to keep quiet, the rest of us will acknowledge what a strain it is on you.

Yes, PHP has some flaws; so do all other languages. There are many metrics by which to judge a language, and you will never find two programmers able to weight them all the same. One metric might be adoption (and thereby the amount of functionality implemented); PHP ain't doing too badly in that respect. If it serves your needs for a given project, its *good enough*.

At least you gave some actual reasons, which is why I'm responding to you and not the thousands of other /. trolls this article is sure to bring out of the shadows.

* poor metaprogramming
This is a valid argument; however, there are a lot of applications where this just doesn't come up. Especially in the realm of web/cgi programming - if you're using anonymous functions, are you *sure* you're not just complicating things unnecessarily? (I've used them, in PHP, but only after serious deliberation..) Something other than a string would certainly feel less icky, granted, but one of PHP's strong points is a fairly simple and consistent syntax.

* global variables for session, cookies, etc.
omg, no main() function! Seriously.. I don't get it. Surely you are extracting the information you need from these at initialization and passing them thereafter?

* no way to refactor object fields. Yes you can use "__get/__set" but those "fake" fields don't work in every place a regular field works. WTF? In Ruby everything is a method, there are no fields, refactoring is a breeze.
__get/__set don't work in some cases to prevent possibly infinite recursion. I don't agree with this decision personally (protecting novice programmers at the expense of clean functionality), but its perfectly explainable, and solvable: call __get/__set explicitly inside the class, or anywhere that __get/__set is already in the stack. In any case, "everything is a method, there are no fields" doesn't sound like the only (or best) way to solve that "problem".

* No "mixins".. I can't write a method and then stick it into multiple classes. Not even with include().
Wrong. There have been several ways to cope with this in the time I've been using PHP. Aggregate functions, the Classkit extension, and now Runkit. (I'd prefer multiple inheritance to any of these, but they *do* solve the problem you describe.)

* Exposes variables vs. variable references. I thought PHP5 would get rid of "&" forever. I was wrong.
Er.. are you saying that the distinction is unnecessary? I'm not sure I understand. FWIW, the new object model eliminates the *majority* of use cases for the &; you still need references to explicitly pass (or return) a primitive, however.

I'm not trying to say PHP is perfect; I have my own list of gripes that I won't bother to go into. But it is good enough for a lot of applications. And language flames are just stupid. Choose a language you're comfortable with that can do the job. If you spend half your time second-guessing yourself over syntax, then using the slightly l33ter language has not paid off.

Propel.

[IpSo_]

Propel is the best I've seen. I'm not a java programmer but apparently its based on a similar java framework.

http://propel.phpdb.org/docs/user_guide/

Try Achievo ATK

[Ivo]

being the author, I'm naturally biased, but you should try Achievo ATK.

It's essentially a 'business framework', targeted at developing web applications. Where other frameworks mainly provide a large set of utility classes, ATK lets you write an application in as few as 10 lines of code.

We're all about inventing every wheel only once. Everything that can be generalized, will be, but anything that the framework automatically offers, can be fully customized.

In one of the replies to this story, I18N and custom security were mentioned. ATK features internationalisation of both data and interface, has several authentication and authorization methods, and lets you add new methods very easily.

Yellow Duck Framework

[Anonymous Coward]

the best OO php framework out there: http://ydframework.berlios.de/

- MVC
- Action requests
- Active records
- Smarty builtin
- Form handling and validation
- Ajax integration
- Pdf on-the-fly
- XML
- DB abstraction supporting MySQL, PostgreSQL, SQLite and Oracle
- Persistent store
- Integrated localization
- XML/RPC
- OO db query language
- Logging infrastructure
- Syndicated XML feeds

- Good documentation (pdf user-guide)
- Forums with quick responses

what do you want more?

What about Seagull

[Anonymous Coward]

I found php to be very quick to start developing with. On both windows and linux, installation of LAMP server is very straightforward and you can test your phpinfo() as soon as it is installed. I have been learning Ruby on and off for a year now and recently I decided to use it more seriously. While ruby itself and rails were pretty easy to install, I can't say the same for Apache conf. and factCGI. Even with all available instructions I was not able to get it right on my Ubuntu and I made a compromise and use Webrick for learning and testing. Without fcgi it takes 15 sec to complete a request on my windows server. Seagull http://seagull.phpkitchen.com/ is an OO framework for PHP that I've had a great success with. It is easy to install, has a site structure with top level menus built in, has user management, permissions, cms etc. Code is easy to follow/understand. Framework is very flexible to develop whatever you need to do.

Hmmm, what for?

[freeplatypus]

Writing a reusable Framework in PHP is quite simple task for experienced developer. I see the advantage of well known frameworks when it comes to employing new developer, but still, learning well designed framework is quite simple.

My question is: Is there something similar to Hibernate for PHP?

Re:Hmmm, what for?

[fyrestrtr]

My question is: Is there something similar to Hibernate for PHP?
The closest thing to Hibernate that I can think of is Propel.

Model, Not Syntax

[Anonymous Coward]

He's not talking about the amount of text in the HTML. He's saying that logic like that in the HTML is a bad idea in both the PHP and templating cases.

Read the last five paragraphs of the parent post. He mentions alternatives.

Re:Pretty obvious answer, but...

[GeraldZ]

it does not make sense to re-invent the wheel. I would say: take what you find and then make it your own. A framework is somthing like a living creature that grows over time, if you feed it right and if it was built for growth. Unfortunately that is not always the case and that might be an argument to build your own because it's not easy to find that out quickly. So I think, the really question is: how to find out if a framework will be able to grow in your hands ? kR Gerald

Here is a reasonably complete list of frameworks

[smagruder]

List of PHP Frameworks

By the way, it's interesting how a thread about PHP frameworks turned into a thread for Ruby-on-Rails zealotry. I won't knock Ruby, but if PHP is good enough for the Wikipedia, Yahoo! and Friendster, it's good enough for me. There's nothing wrong with wanting to become a guru in one language (that happens to be in the top five in popularity!) than becoming a jack of all trades.

Drupal!

[metaclous]

Drupal rocks.

my favourite is xoops

[jst4fun]

its open source and supports ldap or 3rd party authentication, object oriented, supports page caching, database abstraction, error handling, module functionality, smarty based templating system and good community...what else you need..

ofcourse right now xoops supports only php4 so dont expect php5 stuff in it...once php5 goes mainstream they are gonna release php5 as per their roadmap http://www.xoops.org/modules/wfchannel/index.php?p agenum=14

The topic is which PHP Framework....

[DrHex]

not whether PHP sucks or Ruby is better or any of the rest of the messages that have NOT been modded down. Come on people. ./ sure is going downhill these days.
 
  To the original poster: As for a framework, I'm not all that clear why you're interested in a framework other than because of what you've read about Rails being a framework for Ruby. If you're looking to use one of them because of the pre-built objects they're giving you then I would think you'd want to spend the time exploring them to make sure the one you look to using allows you the greatest flexibility for what you're doing. Otherwise, I would just work with PHP5 and build up your own collection of objects that you can re-use as you need. Isn't that the whole point of the object oriented model?

Just my two cents.