PHP Cookbook 238
| PHP Cookbook | |
| author | David Sklar and Adam Trachtenberg |
| pages | 608 |
| publisher | O'Reilly |
| rating | 9 |
| reviewer | Edmond Lau |
| ISBN | 1565926811 |
| summary | Solutions and examples for PHP programmers. |
The approach that the authors use in PHP Cookbook is great. Like most computer books, the authors usually include a summary (in sentence forms) to illustrate what the readers will expect in each chapter. Skalar and Trachtenberg take this even further by including some preliminary (code) examples to explain the general ideas behind each chapters. The examples in the book are self-contained. In most cases, I've found examples to exactly fit my needs -- this makes it one of the better reference books.
Each chapter in the book is divided into multiple sections of Problem / Solution / Discussion with a FAQ style. In each case, a simple description of a problem is followed by a PHP script as the solution. But the meat is actually in the discussions: in-depth details are included here, where the authors also include references, extended ideas, and scripts to inform the readers how much more they can do about the issue.
For example, I was going to add a simple script to my website to parse RSS/RDF files from certain news websites (CNN, Slashdot, ...), and use it as my Mozilla homepage. (Who wouldn't?) This script seems to be simple, but I may make a mistake here and there. As reference, I opened up the book to the section "Parsing XML with SAX." Then I realized the authors already had the script to parse RSS/RDF files in the discussion. Bravo!
For myself, the most useful chapters I found are: Web Basics, Forms, Database Access, and XML. There are also good examples in topics such as security, internationalization, and file processing/management. However, this book does not cover the basics of PHP. If you are a good programmer, you should be able to get away with this using the PHP Manual. A good book to learn PHP is Programming PHP, also by O'Reilly.
Although this book covers a wide range of topics, it does not cover topics like generating PDFs. I would also like to see the authors add one (maybe two) case studies in later editions. That would give the reader a more concrete example of how to combine tricks presented by this book. Other than that, at the price of $39.95 (or $61.95 CAD), this book is a great buy!
Topics
- Strings
- Numbers
- Dates and Times
- Arrays
- Variables
- Functions
- Classes and Objects
- Web Basics - available online as example chapter
- Forms
- Database Access
- Web Automation
- XML
- Regular Expressions
- Encryption and Security
- Graphics
- Internationalization and Localization
- Internet Services
- Files
- Directories
- Client-Side PHP
- PEAR
You can purchase the PHP Cookbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
PHP Security (Score:5, Interesting)
One thing I would like to see more PHP books do is to cover the various Security problems that are prevalent in many PHP based web applications.
Don't get me wrong, I find PHP to be the best and friendliest solution for many things, but some of the Security problems could easily be avoided with some common sense security advice.
Re:PHP Security (Score:4, Interesting)
Of course, writing secure code isn't specific to a language and any book on writing secure code should help to pave the way to avoid common mistakes, just substitute PHP for language X. For instance Writing Secure Code [amazon.com] by Michael Howard could be a good companion book to any programmer's library.
Hopefully, in a few years PHP will have a large enough installed user base (as I think it already does) that the advances issues such as security, tolerance, etc. will be dealt with in entire book(s). Can you tell I am a PHP afficianado?
Re:PHP Security (Score:5, Insightful)
PHP has a couple of common mistakes, but I'm far more apt to trust an inexperienced PHP programmer over an inexperienced Perl programmer, as far as secure code goes.
Re:PHP Security (Score:2)
One thing I would like to see more PHP books do is to cover the various Security problems that are prevalent in many PHP based web applications.
I completely agree with you. David Sklar (one of the authors of the book reviewed here) gave a very interesting presentation about the subject of security in web applications at the International PHP Conference (May 2003) in Amsterdam. You can view the slides of his talk here [php.net].
JP
Re:PHP Security (Score:3, Informative)
It's called phpkeychain [sourceforge.net] and it's modelled after the keychain mechanism in OS X.
'web apps' (Score:3, Insightful)
I think a large part of the problem is that PHP is illsuited for many of the larger web applications it is being used for. Traditional Application Server features such as tag libraries found in JSP, ColdFusion, etc. would be good for separating the 'coders' from the 'presentation designers' in large projects, but that's not pertinent to security.
What gets large PHP web applications like web based mail user agents, like Squirrelmail, and content management systems like PHPNuke is that they have to keep a lot of temporary resources between user actions in a single session. Resources such as open files, sockets, variables in memory, for instance.
PHP's simple engine, and its lack of language features to support these features forces PHP web application developers to build and destroy many of those resources in the life-cycle of the script instead of the life cycle of the application or the user session that is more appropriate.
The larger the application gets, the more difficult it gets to build using the simple 'web scripts' programming paradigm PHP and Perl pushes developers towards. This affects security and performance.
The end result is heavy dependence on databases for variable persistance and error-prone algorithm concoctions, a la PHPNuke et. al.
Re:'web apps' (Score:2)
Yes, but PHP has sessions. At my work, we use the session features to do variable persistance. What am I missing? I'm sure I've failed to grasp the crux of your argument.
Re:PHP Security (Score:2)
some of the worst problems e.g. register globals on as the default setting has disappeared in the latest versions, but I generally agree.
I have this book, and it has got some good examples I have been able to adapt and use, but it does need a good understanding of PHP, SQL and HTML to get the most out of it.
If you want a starter/ reference book, wait a few weeks until PHP5 comes out, and I will be spending my dollars on Leon Atkinson's latest edition in the Core series.
YES!!! (Score:5, Funny)
In all seriousness I enjoy PHP because it is pretty self explanatory, and it can use plain old html inside it too. It's just nice to use a scripting language for the web that was made for webpages originally, not a language that was created for ...
Re:YES!!! (Score:3, Funny)
OR
Pathologically Electic Rubbish Lister
Re:YES!!! (Score:2)
A backronym [science.uva.nl], and not a really good explanation of Perl's reason for being. See here [thepen.com] and here [perldoc.com] for a better background on Perl.
Re:YES!!! (Score:5, Informative)
Duck tape was invented during WWII by Johnson+Johnson for the purpose keeping water out of ammunition cases -- it was relatively waterproof, hence the reason people in the military started calling it "duck tape."
You should try watching the History Channel more often.
Re:YES!!! (Score:2)
Re:YES!!! (Score:2)
Re:YES!!! (Score:2)
To manipulate text. Funny since everything is going to a text/XML type of meta format Perl is very well suited to the Web and to system management or for small GUI programs. I think Perl would be a great replacement for say VB.
*Obligatory PHP flame from the Perl guy*
of course Perl can do all that and it doesn't need_a_function_for_everything() to accomplish it either.
*/Obligatory PHP flame from the Perl guy*
Re:YES!!! (Score:3, Funny)
No, it just needs a module_for_everything.pm
Re:YES!!! (Score:2)
What seems to scare people about perl is that there as so many different ways that you can tackle a job like building dynamic web sites. Perl on it's own doesn't forcefeed anything to you, it lets you find your own style. Many people who start with perl will try to do everything from scratch instead of finding one of the many development environments that simplify things for you a clean framework for developing web applications. Some examples are Axkit, HTML::Mason, Template Toolkit, Embperl, Apache::ASP, CGI::Application, Apache::PageKit, and many more.
Anyway, this article is about PHP, and I won't knock it just because I'm a perl developer. I actually used PHP quite heavily back in 96 when version 2 was just coming out. It was a fantastic tool (even back then) and really let me cut my teeth on dynamic web development. However, I have wandered over to the perl camp, because it is a better tool for me.
Re:YES!!! (Score:2)
Anyway, because the brunt of most simple CGI applications is text processing, perl got moved into being used for that.
Re:YES!!! (Score:2)
Perl stansds for "Practical Extraction and Reporting Language". Invented in 1987 by Larry Wall, it was originally used for in system maintenance tools for UNIX, mostly parsing logs and foramatting the results for display on the screen.
Another book with similar title (Score:5, Informative)
Re:Another book with similar title (Score:2)
Most of books are for most of peoples. The smarter the subject the fewer people can understand and demand it.
That's why you see most of books about VB, ASP, JSP, PHP. Less about Perl/CGI. Even less about Python/CGI. Just 2 good (totally 4 found) books about Zope. No books (at least in several stores I've checked) about web-programing with Lisp, Scheme, OCaml or Haskell.
Well, in the past the reading the hard-printed books was a sign of smart/educated people. Now we are living in the other millenium when:
- online texts are the only reliabe source about smart and quickly evolving technologies (try to find any books about Gentoo Linux);
- smart people are capable to find needed info somewhere online, while lazy/stupid people are not capable to find anything on the web and have to go to a book store;
Conclusion: some day in future we may pro-claim the death of hard-printed books. But we might already pro-claim the death of smart books.Ain't php great? (Score:2)
It would take a whole lot of perl code to achieve the same functionality that can be accomplished in 200 well-written php code. (Depending on what it did - it's based off my personal experiences).
In addition, the ability to mix and match html/php on a cross-platform programming language, as well as write scripts that also run on the command line is worth it's weight in gold (note to people who don't understand that saying, it's really valuable to me). Although perl and cgi scripts can be ran from the command line, they can't have (X)HTML mixed in quite as easily.
Re:Ain't php great? (Score:3, Informative)
You obviously don't know Perl, at the very least you don't know about CPAN. How about a decent HTML parser for PHP. XML? How about this: write a program that reads an Excel spreadsheet and uploads its content into a database and let me know how long it takes you in PHP.
PHP sucks because there is no standard way to extend it, and don't mention PEAR as it so poorly documented its almost completely unusable save for a few of the 'modules' that are there.
Rather than implement proper namespaces the developers chose to throw everything in the core language. Thus you get a_function_for_everything() which sure makes it easy for the web monkeys to memorize it or look it up but never how or why something works, and in the end you get nothing more than an unmaintainable mess. What happens when a new feature is needed. Re-write city (Yes that is a rant because I've had live in the shadow of my web-monkey predecessor).
Also what's with mixing data and logic? PHP's whole premise is just plain backwards. Just recently are they trying to bolt on some sort of templating.
Other problems: no access to the web server, difficult to generate web-server response codes. Errors, including full path-names etc are spit out to the user. (great for security).
Its been my experience in dealing with both PHP and Perl that proper, templated, documented code takes about the same amount of time and code. And with all the hacks to work around the above problems with PHP, its just easier and more maintainable to use Perl. (Too bad my employers don't see it that way)
Re:Ain't php great? (Score:2)
For general web stuff, I normally choose PHP because of it's ease of use in most situations. For those that require heavy lifting, like heavy duty parsing of various document types, I use perl.
Perl is an awesome scripting language - I use it every day for a wide variety of things, but for fast and easy webbased DB apps, PHP is hard to beat.
Re:Ain't php great? (Score:4, Informative)
If that is a challenge, then I accept. I can guarantee you that for every command in PHP, there is an equivalent command (or module) in Perl. Hence you should be able to write this imaginary program in exactly the same number of lines...
Have a look at Embperl, HTML::Mason, Apache::ASP for a couple of examples of how to do this. Most people who knock perl have never discovered the right tools. Personally I would never use those tools, because I am a strong believer in the separation of Code and HTML. I use a templating system for all my projects, and you will never see one HTML tag in my code. Once you work with a team of developers and a separate team of designers you will understand the need for this separation.
PHP is a great tool! I have used it for several applications in the past (6 or 7 years ago). But if you think that PHP can do more than perl can then you are mistaken...
Re:Ain't php great? (Score:2, Insightful)
Well, it'll be a module, not a built-in; Perl's built-ins are often powerful in the broad thermonuclear sense, but are never web-specific. Two key differences remain, though.
One: The Perl modules will have 15 dependencies each, 3 of which are no longer available at CPAN and which have to be hunted down from a Taiwanese mirror using archive.org.
Two: The various Perl modules you need will use different and incompatible pet data structures as preferred by their various developers, so you'll spend extra time writing glue code - vs PHP where you just use the function and go.
Perl HERE docs (Score:2)
For example,
php embeds code-like active statements in between static html. where as perl embeds HTML text in between perl commands. Each of them requires designated separators to keep the text and commands separated.
to be a little more specific, since perl had HERE statements one can have an entire perl cgi script that basically looks like a an html page:
sample perl cgi script:
print HERE1 # slashdot wont print the less than signs
this is a bunch of html here.....
HERE1
$d = 4.5 # some perl commands
print HERE2 # slashdot wont show the less than signs
more $d lines of perl
HERE2
I dont see how the separators in perl between HTML text and perl commands add any bulk or inconvnience. Yet perl can do so much more than PHP.
hence my orignal query. What am I missing here. why is there any preference for PHP? is i somehow faster or lighter weight on APACHE? (that say fastCGI is not). I'm stumped. someone please explain!
Re:Ain't php great? (Score:2, Funny)
rmstar
Buy a Book v.s Web Resources (Score:5, Insightful)
I've been doing PHP web development on and off for a couple of years now and I've always found that it's greatest strength has been the availability of very god online resources.
PHP.net [php.net] and many other excellent resources are only a browser click away and remain up to date for free. PHP is one of those areas where I'll save my money and buy a book I'll get genuine reference use from.
Re:Buy a Book v.s Web Resources (Score:3, Insightful)
Re:Buy a Book v.s Web Resources (Score:2)
Re:Buy a Book v.s Web Resources (Score:2)
I can still fit more useful content on my desk than I can on a single visible desktop.
Re:Buy a Book v.s Web Resources (Score:2)
Just because I can easily find a way to do X on the php.net site (which is admittedly where I've learned shitloads), doesn't mean the methods found are any good...
The Cookbooks are wonderful! (Score:2, Insightful)
Things PHP is missing (Score:4, Insightful)
2) Native XML support - It's just not there? Why re-invent the wheel each time? Give us a good XML tree-walking engine DAMMIT!
3) sane and consistant functions. Single quotes, double quotes, some functions work with both, some work with one or the other, embedded html in an echo screws up if you don't double quote it, etc.
4)
In short, PHP is a good language for small projects, but just doesn't cut it in an enterprise setting.
Re:Things PHP is missing (Score:2, Informative)
http://pear.php.net/
Re:Things PHP is missing (Score:5, Informative)
I believe there is a PEAR package [php.net] that abstracts an OO layer over the functions to various databases. Think DBI for PHP.
2) Native XML support - It's just not there? Why re-invent the wheel each time? Give us a good XML tree-walking engine DAMMIT!
Natvie XML support is there. A SAX parser is usually built in by default. I'm happily using a DOM XML interface that I compiled into my version.
3) sane and consistant functions. Single quotes, double quotes, some functions work with both, some work with one or the other, embedded html in an echo screws up if you don't double quote it, etc.
Quotes in PHP do work in a sane and consistent way, very similar to the way they work in PERL. The only thing I mourn is the lack of a qq[-like facility (and I wouldn't be surprised if someone snuck it in while I wasn't looking, and I just didn't know about it).
4)
Um.... why?
Re:Things PHP is missing (Score:2)
Quotes in PHP do work in a sane and consistent way, very similar to the way they work in PERL. The only thing I mourn is the lack of a qq[-like facility (and I wouldn't be surprised if someone snuck it in while I wasn't looking, and I just didn't know about it).
Not yet, AFAIK, but you can always use the heredoc [php.net] syntax to achieve the same effect -- the only problem is that the heredoc terminators kind of disturb your indentation. Still very useful for large string literals....
You aren't looking in the right places. (Score:2)
The parent poster complains about "consistant (sp) database integration" as one of the main problems with PHP. This is usually a problem noted only by those who haven't used PHP in serious development. Sure, if you're writing a 20-line script that you know is only going to use MySQL, then who cares what database connection statements you're using. However, if you're writing anything that needs to be more serious and portable, check out one of PHP's database abstraction libraries: ADOdb [weblogs.com] or Pear DB. [php.net] Both of these libraries will let you abstract out database functions so that they aren't tied to one specific database.
Personally, I prefer ADOdb. Not only is it faster than Pear DB, but there's also a C port to speed it up even more. ADOdb also has more capabilities, and its author hangs out in their forums and is extremely helpful with user questions.
You have to change your mindset a bit to code with ADOdb or Pear DB, but it's worth the bit of extra learning curve to gain portability. Since ADOdb can generate insert/update SQL and also generate HTML tables, I find that I'm faster coding with it than I ever was with mysql_query()... and I can switch to Postgres or Microsoft SQL Server at any time without really thinking about my database code.
I hope this helps those of you who are still stuck with mysql_query() or similar. <plug>Also, we're a web hosting company [simpli.biz] that supports PHP 4.3.x, ADOdb and Pear DB, and we will answer your PHP questions as part of your web hosting package.</plug>
Don't judge PHP/XML yet, look forward to PHP5. (Score:2, Interesting)
There is a lot of work on a complete new DOM extension, which should clean up the mess done in domxml as of PHP 4. It will follow the W3C DOM API as much as possible and is completely rewritten from scratch.
Furthermore Sterling Hughes is working on SimpleXml [edwardbear.org]. An extension which should make it much easier to access XML Documents with the usual PHP functions.
The SAX Parser in PHP 5 will also be based on libxml2 and not anymore on the aging expat library.
XML Validation, XPath and XSLT support are also currently revised and should be improved a lot in PHP5.
Re:Things PHP is missing (Score:2)
Try ADOdb [weblogs.com]. It is a database access library for PHP which seems to work well.
Re:Things PHP is missing (Score:2)
There are legitimate criticisms of PHP, but these aren't them.
Re:Things PHP is missing (Score:2)
1) consistant database integration - Why not have a SetDBType() function, rather than hardcoding mysql_connect, mssql_connect, myodbc_connect, pgqsl_connect, etc?
Because different databases do different things, and abstracting degrades performance -- you CAN, however use ODBC with PHP. I do abstract whenever time allows. Manual abstraction is easy. There's a DB:: class in PEAR [php.net] as well as ADOdb [weblogs.com].
2) Native XML support - It's just not there? Why re-invent the wheel each time? Give us a good XML tree-walking engine DAMMIT!
php.net/xml [php.net]
3) sane and consistant functions. Single quotes, double quotes, some functions work with both, some work with one or the other, embedded html in an echo screws up if you don't double quote it, etc.
Quotes always work consistently. If you're thinking of Magic Quotes, it's a "feature" put there to make newbies not do stupid things. It can be turned off, and worked around very easily. I will, however, give you that function naming could use an overhaul, but in order to save backwards compatibility, this has not been done. The parameter order of implode [php.net] vs. substr [php.net] is confusing, and easy to forget.
4)
This might not be exactly what you're looking for, but the January issue of PHP Architect has an article on using PHP with the
Enjoy. PHP is not all things, but it does a GOOD job on the web.
S
Re:Things PHP is missing (Score:2, Informative)
As a side effect, implementing one database call, even with a db_type parameter in the database calls, gives a certain level of abstraction which would allow for greater cross portability. It also helps with application debugging, generating the error closer to the actual failure point, rather than in the wrapper class itself.
Sick and tired of this (Score:2, Insightful)
I'm a PHP/MySQL junkie, and every time I see anything about PHP on
</rant>
Good learning tool (Score:2, Insightful)
The examples of integrating to MySQL were especially useful as I have been playing with Microsoft Access using MySQL as server, and now I can easily create web views from the database!
Hmm (Score:2)
Re:Hmm (Score:2, Informative)
An entire chapter [php.net] in the manual for it.
The perfect companion for this book... (Score:4, Informative)
JP
Re:The perfect companion for this book... (Score:3, Funny)
News? Publish date = Nov 2002 (Score:2, Insightful)
Excellent book, I heartily recommend it to any... (Score:4, Informative)
Relevant, real-life useful examples are given and even a seasoned pro like me picked up a few gems like the example user authentication code that utilizes a hash instead of having to go back to the database on each page fetch.
My bookshelves are full of PHP books but most of them are inferior to the online documentation at php.net. They add nothing and are a true waste of trees. This one, however, does not fall into that category.
I'd give anything (Score:3, Insightful)
At worst, every database connection is hard-coded in a different place and there are no comments anywhere.
In either case, my God help anyone who wants to add functionality. These same people need a good book on relational database design, or be subjected to 4 years of universigy RDBMS design courses like I was. IMO, if you aren't willing to slit your wrists to get out of an RDBMS design class, you haven't taken enough of them.
Re:I'd give anything (Score:2)
What? No OOP fight? (Score:2, Funny)
Re:What? No OOP fight? (Score:2)
Wait for PHP5. :)
Definitely Worth the Buy (Score:2, Informative)
I would be ecstatic... (Score:2)
Instead, I've got to write ugly crap like "if (strpos($alltext, "This string") >-1)" in order to check if a variable contains a string.
In Perl? "if ($alltext ~= "This string")". Much nicer.
Re:I would be ecstatic... (Score:2)
if (preg_match('This string', $alltext))
Re:PDFs? (Score:3, Informative)
Re:PDFs? (Score:5, Informative)
"An open file format specification, PDF is available to anyone who wants to develop tools to create, view, or manipulate PDF documents."
Re:PDFs? (Score:2)
*Obligatory PHP flame from the Perl Guy *
Of course unlike Perl there are no easy/good ways to create one in PHP
*/Obligatory PHP flame from the Perl Guy*
All PDF generators suck (Score:3, Insightful)
Of course unlike Perl there are no easy/good ways to create one in PHP
*/Obligatory PHP flame from the Perl Guy*
There are no good ways to create one in any language. Current solutions are either:
(1) A thin shell over text and graphics primitives
or (2) dependent on an external rendering engine which creates another format like Postscript.
I'd like a high-level PDF creation library that would let me, say, directly create a table that is sized to fit the contents like HTML, but unlike HTML, will split the table across multiple pages, repeating header and footer information. Sounds straightforward, right? Not possible now. I've checked with Adobe engineers, and it's not even possible with their $20K PDF generation toolkit.
I can just hear the XSL-FO people saying, "but it IS possible with XSL-FO." And it's also possible, given all the sand and steel you could possibly need, to build a window. Point is, it's currently way too much trouble. I'm sure it'll get there eventually, but PDF creation is really an idea in its infancy right now.
Re:PDFs? (Score:3, Informative)
Re:PDFs? (Score:2)
No, PDF is open... (Score:5, Informative)
If you're interested in generating PDFs from PHP, there are a myriad of options available by searching Google [google.com]. Some web hosting companies [simpli.biz] also support generating PDFs from PHP, which makes generating PDFs a cinch.
HTH!
Re:PDFs? (Score:3, Informative)
And, yes, it appears to be legal. (It better be, considering I use it at my job.)
Re:PDFs? (Score:4, Informative)
Can you generate a PDF with PHP without also generating an Adobe lawsuit?
There's no liability shield built in, but FPDF [fpdf.org] is a great tool that can generate PDFs using PHP without the need for using a commercially-licensed (read "expensive") PDF generating library. I like it because it is distributed under a BSD-like license.
Student Suspended Over Suspected Use of PHP (Score:3, Funny)
"A teacher overheard him say that he was using PHP, and as part of our Zero-Tolerance policy against drug use, he was immediately suspended. No questions asked," said Principal Clyde Thurlow. "We're not quite sure what PHP is, but we suspect it may be a derivative of PCP, or maybe a new designer drug like GHB."
Parents are frightened by the discovery of this new menace in their children's school, and are demanding the school do something. "We heard that he found out about PHP at school on the internet. There may even be a PHP web ring operating on school grounds," said irate parent Carol Blessing. "School is supposed to be teaching our kids how to read and write. Not about dangerous drugs like PHP."
In response to parental demands the school has reconfigured its internet WatchDog software to block access to all internet sites mentioning PHP. Officials say this should prevent any other students from falling prey like Brett Tyson did. They have also stepped up locker searches and brought in drug sniffing dogs.
Interviews with students suggested that PHP use is wide spread around the school, but is particularly concentrated in the geeky nerd population. When contacted by BBspot.com, Brett Tyson said, "I don't know what the hell is going on dude, but this suspension gives me more time for fraggin'. Yee haw!"
PHP is a hypertext preprocessor, which sounds very dangerous. It is believed that many users started by using Perl and moved on to the more powerful PHP. For more information on how to recognize if your child may be using PHP please visit http://www.php.net.
Re:Student Suspended Over Suspected Use of PHP (Score:2)
Re:Best of all (Score:2)
Re:Best of all (Score:2)
Re:Best of all (Score:2)
Re:Speaking of FUD (Score:3, Insightful)
That doesn't even remotely make sense. Most browsers have javascript built-in, so that should decide what language to use server-side? Personally, keeping javascript for client-side and PHP or whatever for server-side is less confusing. That contextual switch is easier when the client-side / server-side code looks different.
Now I'm off to find a review of a Javascript book, so that I can insert random comments about what a shitty little language it is. That will be quite helpful for someone who wants a book about Javascript, I'm sure.
Re:Speaking of FUD (Score:3, Informative)
Remember, PHP is to ASP as Zend is to VBScript.
Re:Speaking of FUD (Score:5, Informative)
You have that ass-backwards. PHP is the language, Zend, the engine. Any other scripting language could be developed and used with the Zend engine.
cool (Score:2)
Can I get an ECMA engine for it?
Re:Speaking of FUD (Score:5, Insightful)
So what are you saying is better than PHP? Running ASP with Javascript (or ECMAscript to be pedantic)?
If you can tell me that handling forms and working with databases can be done better with something other than PHP please do.
Also, please tell us what is a 'bigger' language, if PHP and *gasp* Perl are so little?
I wonder because I started in ASP with VBScript. I learned Perl and PHP and now I do PHP pretty much full time. If I want a script that is blantent CGI I use Perl. To me PHP and Perl completely blow away (not blow chunks) ASP with VBScript -- they are far better languages for web development. I can't say exactly why I think that, but one of the main things for me is the quality of the community surrounding the language. There's a lot more user support for PHP and Perl which to me is more helpful than the MSDN library will ever be. I also like a lot of punctuation -- but that's just a personal preference.
As far as switching back and forth between languages (JavaScript and PHP, for example), I never thought it was so silly. To me, doing things client-side is distinctly different from doing things server-side. It's no problem to have different languages for those two things. Especially when have to limit what you do on the client side because every browser is different. It seems to me like wasted effort to spend to much time on JavaScript stuff, because lo and behold browser X won't support what I'm trying to do. If I do it server side in PHP, I have an easier time writing portable code.
You certainly have a right to advocate your language of choice, and probably a right to bash others, but could you explain yourself a little better?
Re:Speaking of FUD (Score:2)
I followed pretty much the same path as you, and once I tried PHP there was no turning back, especially once I discoverd the Smarty Template Engine [php.net]. Everyone doing PHP development should check it out.
Re:Speaking of FUD (Score:2)
This is going to sound like such a flame, but it's not, honest. What's the benefit of using something like Smarty over just not putting anything besides control flow or variable output in your HTML files? I keep all the real work in a separate file, and never have anything more interesting than for(;;){ foo } in the file with the HTML. And no HTML in the code file, ever. It's always seemed like another layer of complexity (and overhead) for very little return.
Or am I missing something?
Re:Speaking of FUD (Score:2)
Some template solutions are not much better then mixing PHP and HTML but others like Smarty are kick ass. In Smarty, you can put simple presentation logic in your templates. For example, with a proper template, you just pass an array to smarty and it will render it into a nice table, highlighting every other row, bolding keywords you tell it too, etc etc.
It does take a little while to get used too, but follow the link in the grandparent and read up on it. It is worth the time I think.
Re:Speaking of FUD (Score:2)
You seem to have missed it before so I'll say it again: you do not need MS in order to use javascript (and even ASP) on the server. And even on my worse day I would not defend VBscript - nor is ASP vbscript, so it doesn't matter. Saying "ASP sucks" is absolutely NOT the same as saying "vbscript sucks" - and vice versa.
PHP has a lot of user developed modules, but it still lacks a lot of the things provided right OOTB with MS ASP (or chilisoft with java). Using java alone will also get you that same power and more, but php on a good day doesn't come close to either even WITH all those widgets.
And if you want docs there are easily as many "javascript toolbox" sites as there are PHP - probably more, in fact, since it IS supported by MS in ASP and most of that code can be used in apache just as well. Honestly, the only thing I can see going for PHP is it's free - and in this case the "free" solution well proves that old adage about getting what you pay for.
Re:Speaking of FUD (Score:2)
Netscape's "solution" was proprietary and costly. They were in the wrong place at the wrong time with the wrong solution; apache was catching on quite well when they were trying to sell kilobuck server "solutions" and balkanize the web - and the geeks who spoke "web" back then (ie you couldn't walk down the street and shout to find a "web developer") spoke perl and cgi. Given the choice of supporting open and community supported vs. expensive and supporting the company that is trying to "own the internet" who would you expect to win that battle?
Re:More PHP (Score:5, Interesting)
1 - It lets you mix html and code in. Sure, it's not the only language that lets you do it, but it's still a strength.
2 - It's free, open source (zend crap excluded)
3 - Microsoft hates it. That's always a plus.
4 - It's increadibly flexible and forgiving. Coming from a c background, this is one of it's most useful features to me. As far as I can tell, most programmers are inherantly lazy; They don't want to work harder than necessary to do a good job. In PHP, types are incredibly loose. If you want to use a string as a integer, a float, and a string all in the same line, you don't have to cast it. It just does it, and the incredibly vast majority of the time, it does just how you expected it to. Why can't C be that smart?
Re:More PHP (Score:3, Funny)
Having a pretty broad background in VisualBasic...
*puts on asbestos suit and goggles*
And, of course, making a typo in a variable name can make debugging a real headache. Because you don't have to cast your variables, anything you type is valid, and typos don't generate errors! (You'll always find "Option Explicit" in my VB modules!)
Having about a month's worth of self-taught PHP behind me, and actually being very comfortable and productive with it, I find that the no-cast variable system works very smoothly. It's a little wierd when it comes to arrays, but good naming conventions help there. It's nice to not have to stop and make a new variable declaration all the time - just code.
And let's not forget the true power of no-cast variables: obfuscation! He's using it as a flag! No wait.. it's a loop counter! NO! It's an array! AAAHH!!
=Smidge=
Re:More PHP (Score:2)
How on earth is this a strength? This "feature" is probably single handedly responsible for a significant portion of the absolute crap webapp code out there.
Seriously why would you ever, ever want to mix your code with HTML? That's just so 1990's...
Re:More PHP (Score:2)
When writing web applications, you should always check for error conditions before writing any HTML to the page. You can do that with any language.
Obligatory Smarty plug (Score:3, Informative)
I thought that PHP did a great job of mixing HTML and code until my PHP apps started reaching a certain size. Even using function calls and classes, templates started getting convoluted. Then I discovered Smarty [php.net] and my whole way of working changed. Smarty is a template manager that allows for more precise separation of content and code. As a super-simple example, lines like become {$variable}. Over the course of a whole site, the savings from this syntax alone ease code readability (yes i care about such a thing). But there's a lot more to smarty than shorter variables, including shorthand for string modifiers and loops, as well as a nifty caching system that can speed up dynamically generated sites, and zillions of other really cool things for "lazy" programmers like me.
A lot of people on this thread have mentioned AdoDB (my other favorite PHP add-on), but I haven't seen anyone give a proper shout out to Smarty. It's made my life easier.
Re:Obligatory Smarty plug (Score:2)
I don't understand this. Why is {$variable} so much easier or less confusing than <?=$variable?>
The last time I was hiring PHP developers (thanks Slashdot!), I had a few people in who did this, and they'd walk me through the code. After looking at it, I'd simply change a few characters to make it use "native" PHP code, and ask, "what's the difference, why did changing a few characters make things so different?" The response I typically got was either, "because this is better," or "the designers said they could work with this better." The first reponse isn't really a reason, and I don't buy the second response, because the differences seemed so slight. So really I have a genuine question: what are the advantages? What am I missing?
Re:More PHP (Score:3, Funny)
Types aren't hidden in PHP
As anyone can plainly see
They are not hidden from your code,
They're right there from the time you load.
With gettype() they're revealed to you,
With *val() you can set them too.
There's so much flexibility
I can hardly contain my glee.
Setting, seeing, casting types,
PHP answers all your gripes.
Re:More PHP (Score:2)
But consider the number of man hours that are in the slash code... it works... it does what they want... and it's in a language that they know well. There's no reason to ever change it.
Re:PHP most pervasive? PERL (Score:2)
while ($phpzealots == "annoyed") {
utter($meaningless_nonsense);
}
}
That wasn't so hard, was it?
Re:Kiss and say goodbye to Java language!! (Score:2)
Re:Kiss and say goodbye to Java language!! (Score:2)
Actually, PHP really needs an app server (ala Websphere) and some sort of Servlet or EJB-like server-side object. The app server could handle database connection pooling properly, caching, application-level opjects, etc. If PHP ever gets to that point, then it will compete with Java on the high-end. Hopefully an improved object model in PHP 5 will start the process.
Re:Kiss and say goodbye to Java language!! (Score:2)
Forget Java man and go to PHP!
PHP is 4 times faster than Java technology 'JSP' (Java server pages).
This tallies because compiled "C" program is 4 times faster than Java.
How on Earth was the above article modded as "interesting"? It's absolute garbage! I use both PHP and Java (and C from time to time) and Mr Coward's "statistics" have zero basis in reality. For one, C is a hell of a lot faster than Java or PHP (unless really really really badly written - like, you'd have to work hard at writing some real crap C code for it to be only 4 times as quick as Java). For another thing, it depends upon the application - Java does have an edge when there's heavy database use, due to it using a pool, rather than PHP's idea of locking a db connection to each httpd child process (which leads to the sight we see rather a lot here, of PHP sites "unable to connect to the database").
The fact that PHP is a "scripting language" should have clued AC in to the fact it's not actually "C" - it's being interpreted, which doesn't make it anywhere near as fast as C. I love PHP (used to use Perl, but never need to touch it any more - even for shell scripts) but I know it has limitations and is not always the best choice.
Re:Enough MySQL (Score:3, Informative)
just like PHP
if you want a big, complex, very scalable website; it might be better to go with java, for everything else (>90% of cases, i'm sure) it's easier to do it with PHP.
just the same; if you want a heavy duty database, with lots of concurrent updates, and/or triggers, stored procedures and so... well you can do it with Postgres or mortgage your house and use Oracle. for everything else, it's easier, quicker; and usually faster to use MySQL
MySQL is not easier than PostgreSQL (Score:2)
Re:The superiority of PHP over Perl (Score:4, Informative)
I did a lot of Perl development before switching to PHP, and some of the things you mention that are missing from Perl are readily available as modules from CPAN [slashdot.org]. But that just adds another point in PHP's favour -- the default install comes with all the stuff you mentioned.
Before anyone gets their Perl backs up, let me point out why a good default install is important for web development: you don't always have control over the server, so you can't always get the Perl modules you want. (But if you want to re-write your code, sometimes, you'll get what you need! (Couldn't resist.))
Re:The superiority of PHP over Perl (Score:2)
I both agree and disagree...
I hate having every_goddamn_function() in the global namespace. I would much rather drag in what I need when I need it, a la perl. However, what drove me from mostly perl development to mostly PHP development is that you're pretty sure you'll have most everything you need built in with the latter. The simple fact of not necessasrily having perl's DBI module installed on a server you don't control (and have no access to gcc on) forced the decision to use PHP for most things over here.
Of course, PHP might not have everything you need built in, either. Need to generate images? If the server doesn't have PHP compiled with gd support, you're out of luck. It does happen less often, though.
The one thing I would love to see from perl is a standard web app bundle. Something that was a no brainer for admins to install when perl's installed. DBI, AxKit or Mason or similar...etc. Something you could count on being there. Then I could get back to a language that fits my brain better.
Re:The superiority of PHP over Perl (Score:2, Interesting)
some (?) web design (??)... how much of it to begin with?
>>Previously I'd used Perl because I'd heard from many people that Perl was the end all and be all of scripting languages for the web. Imagine my suprise to discover that PHP was vastly superior!
Perhaps your surprise came from the fact that you were using CGI Perl and that PHP was a fast Apache module? You'd be surprised to learn, though, that today there's also a Perl Apache module as well which is as fast or faster than PHP's...
>>I know this is a bold statement, but I have solid arguements to support it.
You better have them as we'll see below...
>>I'm not arguing that PHP is better than Perl in all cases. There is certainly still a use for Perl.
Actually, it's the contrary: Perl is one of the most flexible and faster high level languages in existence. It is used for nearly any tasks imaginable dealing mostly with character string processing, that is, it's an overall great general purpose Turing machine. PHP for some misterious reason is used solely as a tool for building html pages, or perhaps PDF using some commercial library...
Besides, you're aware that php was born from Perl, aren't you? They just dumbed it down so as not to scare ex-M$ users away and because of this the language just lost much of its strengh and flexibility. Ever heard of Perl's motto: "There's more than one way to do it"? It means you can express the same computation many different ways. It means, for instance, that you may express in purely procedural fashion or object oriented, where you see fit. In php (and Python as well) you're trapped in OO craze. There's just one way to do things.
Also, Perl is one of the most compact (and therefore faster) languages in existence. Of course, people's unwillingness to learn the language make them look at features such as "do { print if
So, i say, i'm not saying Perl is better than php in all cases, there's certainly still a use for php...
>>Finally, I'm not the most talented Perl programmer out there.
That seems obvious!
>>I generally prefer to use the vastly superior Python, but can use Perl if I have to.
I like Python too and highly regard it to be Perl's spiritual brother. But i wouldn't say one or the other is better. Though i would take Perl's flexibility and compactness over Python's rigid OO syntax anyday. One thing is true: they both beat the crap out of php and its VB-like stand...
>>* Ease of use. I would definitely not recommend anyone new to programming begin with Perl.
I wouldn't say ease of use is one of Perl's deficiencies. But surely the learning curve for the language is kinda steep. Still, power comes at a price and if you are willing to use a powerful tool you'd better learn how to use it and use it well.
I can say once you learn Perl right, most other languages just feel like lacking in flexibility, expressiveness or compactness.
Yes, if you never used a katana, you'd better get to grips first with a bamboo stick or something.
>> * The OO of PHP is excellent. In my experience, it rivals Smalltalk.
Who do you think you're fooling? PHP's OO features are more like Javascript than Smalltalk, stop daydreaming. If you want high level OO stuff go with Python's multi-inheritance model.
>>Hopefully Perl will be patched up so it supports such must-have OO features like introspection, reflection, self-replication and ontological data-points.
When there's real need for such features, yes. Because Perl doesn't force you into OO syntax, many constructs which just make sense in a purely OO view of the world are not really need