Slashdot Mirror
Programming PHP
This book begins as most O'Reilly "Programming" books do: with a brief introductory chapter. In Programming PHP, this chapter is very short, so don't look to this book for a gentle introduction. On the other hand, this is the perfect book for you if you are just looking to learn a new scripting language. The following chapters go over syntax, data types, built-in functions, etc. These chapters are a little dry, but move quickly and effectively demonstrate the unique features of PHP (as compared to other scripting languages).
Of particular interest to programmers who are interested in expanding their horizons to developing dynamic web pages are the chapters on PHP web techniques, security, and application techniques. The web techniques chapter gives a quick overview of HTML and the GET and POST methods (and why you would want to use one or the other). It then covers a lot of useful tips and tricks that may be foreign to someone who has done little or no web development. Topics such as getting server information, form processing, sticky forms, file uploads, document expiration, and authentication are covered. It ends with an excellent discussion of maintaining state from page to page and visit to visit, covering cookies and PHP's (very cool) session support.
The security chapter covers standard things you want to keep in mind when creating dynamic HTML. No surprises here, but it is always good to be reminded. The application techniques chapter starts with a collection of best-practices, tips, and tricks to make your development process easier and better. It concludes with sections about error handling and performance tuning. As with the security chapter, there is nothing here a good programmer doesn't already know, but you can never hear it too many times.
I think this is a great book for programmers who want to start developing dynamic web sites with PHP. It gives a detailed overview of PHP, lots of valuable tips, and a good sense of PHP's strengths.
As someone who has written a lot of code, but only a little CGI, I really liked the chapters that discussed application development techniques specific to the web. Along those lines, not much time is spent on standard coding techniques, so if you want to use PHP but have never written any serious code, you may want to look elsewhere for an introduction. For the rest of you, just think, you may never have to use CGI.pm again.
The index seems adequate, although I must admit I did not use it much on the first read-through. The book is so well organized that, when reading it, you do not have to flip around much. Perhaps someone who has used this book as a reference can comment further on the quality of the index.
Contents are available on O'Reilly's page LinksSee Rasmus's page for links to where you can buy the book (maybe he gets a kickback for the link). Of course, you could always go to a local bookstore and purchase it.
You can purchase Programming PHP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
It redefines the paradigm of online programming. Programming PHP, like PHP itself, marks a watershed in programming history. Generations from now technology historians will divide the time line into two periods: PPHP (Pre-PHP) and PPHP (Post-PHP). The PHP language, just like the book describing it, is beyond compare. Coupled together they have created a force for Good that rivals Superman, God and Scooby Doo all rolled into one. My next child is going to be named "PHP Programming Lastname".
No contradiction:
You're an accomplished programmer but a PHP newbie then buy it.
Your a newbie to programming then there's prolly a "for dummies" out there.
Or, HIBT HIL and I'm having a nice day thank-you
Get the EULA T-shirt
As a semi-competent Perl hacker I found PHP very easy to pick up, and I imagine the same would be true for anyone with some degree of coding experience. The only reference I find myself using regularly is the excellent PHP website which provides a pretty decent tutorial and a thorough and searchable command reference. Combine that with the fact that the manual is annotated by PHP users and the only reason for having a dead tree reference is to have something to read in the bath.
Still, buying it does at least give Rasmus some money...
"Are you being weird, or sarcastic?" said Emma. I said I didn't know because I get the two feelings mixed up.
The other day while I was waiting for a friend a Barnes and Noble, I picked it up only to put it back on the shelf ten minutes later. Usually I buy every Oreilly book for technologies that I use frequently, but I figured that there is probably very little in the book that PHP's excellent online documentation doesn't provide.
www.php.net/mysql_query
www.php.net/strftime
I've found this most useful: you only have to type a few more keys besides the function name to get the documentation, kind of like man pages.
There is no denying that the php.net/manual site is a good comprehensive resource. I do get tired of people suggesting to avoid books and just use the online manual. Obviously, they both have their places.
:)
The first strike against the online manual is that it's not portable. Downloading in most of the portable formats loses the user contributed comments, which are really what make the online version as helpful as it is in most cases. Seeing how other people have worked around issues, or just posted small extra example snippets is often a lifesaver.
However, where books can come in useful is the depth. The biggest drawback of MOST PHP books is that they are thin on detail - sometimes a 500 page PHP book has less than 200 pages of 'useful' content, and often times its still elaborated examples of basic 'form submission' code. 200+ pages of reprinting the manual is often not useful for too many people. Yes, it's portable, but I don't need pages of mSQL commands, for example, printed in any book.
The few good books I've seen regarding PHP that are more in depth and less 'manuals' include the new Professional PHP4 XML (not perfect, but certainly useful if you need to do XML, although that's a moving target in PHP), PHP 4 Web Applications (from New Riders, kinda thin, but many good techniques over and above the usual PHP stuff) and a couple others which escape me. Probably only 20% of the books published actually contain useful stuff you won't find by combing the manual or various discussion boards.
Also, in defense of books, some people just learn better by being able to read and see examples (which is why the books should have more good examples and fewer filler pages of manual reprinting). Similarly some people do better with hands-on training than with forums or books, which (small plug) my company provides (http://www.tapinternet.com/php/).
creation science book
- xmlrpc: works
- SOAP (via http, https or smtp transport): works
- CORBA (ORBit / satellite): works
I've probably overlooked some more but it should still get you startedyou have moved your mouse, please reboot to make this change take effect
PHP is certainly not intended to be a middle-tier language, which is where remote calls would be most useful. That said, there's no reason some time couldn't be invested to find a work-around. Many C libraries can be wrapped with ease and accessed from PHP. Find a C library that allows for RPC (or remote object calls) and wrap it. Nevermind the ease with which Java classes integrate with PHP (its dead-simple) and Java's well known RMI (et al) support, you should be set.
:)
As other posters have mentioned, PHP doesn't need to natively do *everything* - that just serves to bloat. But, it ought not *prevent* anything (which is Perl's mantra, too). For the most part, this is the case, especially with the Java integration. Between PHP and Java, if you find something that you can't do, I'd be most surprised. And if so - just use Perl
Cheers.
I think your view is unbelievably pretentious considering that according to this the U.K. had 3.7 million active businesses in 2001 and of them 99.1% were small businesses (under 50 employees).
And, according to this in the USA:
Also, small businesses...
- provide approximately 75 percent of the net new jobs added to the economy.
- represent 99.7 percent of all employers.
- employ 53 percent of the private work force.
- provide 47 percent of all sales in the country.
- provide 55 percent of innovations.
- account for 35 percent of federal contract dollars.
- account for 38 percent of jobs in high technology sectors.
- account for 51 percent of private sector output.
- represent 96 percent of all U.S. exporters.
Gee, now I see your point. You're right: PHP is useless to just about everybody out there.http://freshmeat.net/projects/php-orbit/?topic_id= 51
PHP-ORBit is a PHP4 module which can be used to easily access services that communicate via CORBA. This is achieved by wrapping the lightweight CORBA ORB "ORBit" used in GNOME.
Isn't Google just great?
It seems to me that web language books need to be split into two groups:
1. Web techniques
2. The language
Once one is familiar with typical web techniques and issues (form handling, state management issues, etc.), then many of the books seem redundant WRT web techniques.
The problem is that "Web Programming Techniques" would probably have to choose an actual language for its examples, so they figure they might as well put them together.
Perhaps Oreilly should split web language books into a language details book, and a "Web Techniques using X" series for those new to web issues (where X is a specific language). They could use pretty much the same material, but simply swap the language for that one.
Web programming issues are pretty much the same in ASP, PHP, ColdFusion, etc. If I need to pick up yet another web language, such as JSP, I don't want to waste book-size and eye-space on the same web issues, I want to get right into the specifics and uniqueness (gotcha's) of the particular language.
Table-ized A.I.
Bookstores are floating in computer books and many of them are little more than repackaged manuals. The authors add little, if anything, to these books. But, if an author brings experience, perspective, insight and skill to a book, then you'll learn something that's not available elsewhere. If you confine your reading to readme files and syntax manuals, you're limiting yourself.
-- Slashdot: When Public Access TV Says "No"
Before starting PHP I had actually done quite a bit of database programming using various languages including Perl. And I agree that database abstraction is useful in some cases, but as soon as your database needs go beyond trivial selects it all falls apart. Try switching from M$-SQL to Oracle halfway through a project. The fact that you used a database abstraction layer might save you 10 minutes of global search and replace on some db-specific function calls, but then you spend the next 3 weeks converting your schemas, stored procedures, triggers and the SQL itself. Try taking an Oracle query that includes DECODE() and make it work on some other database! A DB abstraction layer doesn't solve any of this.
(Well, some try to solve the schema issue by forcing you to describe it in some generic XML format, but you still need to get in there and get your hands dirty to make sure the different types each db supports are handled correctly)
When I write applications I write it with the databases I want it to run on in mind. I write database-specific functions to fetch data, update data, etc. I do this so I can use all the DB-specific performance tricks I can. And I will simply state that this application supports MySQL, PostgreSQL and Oracle, for example. If someone comes later on and tells me it needs to support another one, ok, then I add that support. For most dynamic web apps the bottleneck is the database. I am completely unwilling to trade performance for portability on that particular aspect. You don't trade away performance on the one critical factor in your architecture.
So, that is why database abstraction is not in the core of PHP and why PHP gives you access to all the intricacies of each database API. Others have layered abstraction layers on top of this low-level API support and that is fine, but PHP was originally designed as a tool for me to solve web problems and as such the design reflected my approach to web-database integration.
If every database conformed to standards and the SQL and schemas were portable, then yes, not using db abstraction would be asinine, but that is not the case, and it will never be the case as database vendors always want to distinguish their product from the next guy's.