The PHP Anthology - Volume I, 'Foundations'
The book is very well-written, often using a question-and-answer heading style that makes searching the table of contents easy. In the preface, we already meet the first cool aspect of the book: lots of links to sites in the form of footnotes.** Yes, most books of this genre include links to web sites, but this way makes a couple of things clear: first, that there are lot of references, so you have many places to jump to for more information, and it's a sleeker text flow: embedding URLs in dead text makes line breaking hard and detracts from the flow of the language. As you read a page, you can note, "OK, that's an online resource," and keep reading without having to stumble over an incomprehensible URL.
Each volume has numerous code examples, and they're all on the book's web page to save you from transcribing. The web site is the best place also to buy the books; they're generally not available in stores.
Chapter 1: PHP Basics
These are the foundations of the book. Quick highlights:
How does one exactly RTFM? The author directs the novice to the PHP web site and explains what each part of the online manual corresponds to. But also, the coolest aspect of the PHP web site is its search-by-url feature. It looks up a function or language reference page, finds a set of likely matches, or just googles the site for you. Try it: http://php.net/array, http://php.net/sprintf, http://php.net/error.
How to understand error messages. Remember your first "cannot add header information -- headers already sent" error. Huh? Learn the difference between parse errors (what you wrote is not valid code), semantic errors (you're asking PHP to do something illegal), environment errors (PHP is not equipped to do what you want), and logic errors (PHP is happy but you're not). The last is particularly insidious (no E_PEBKAC level of reporting), but unit testing (see Volume II) gives you hope to find and fix those.
How to include. What is the difference between include and require (answer: require forces a fatal error if it can't find the file you want, while include only warns)?
How to write portable and reusable code There are hundreds of configuration directives, and using them can make one of your applications simpler. But some are to be used only with careful consideration. The magic_quotes_gpc directive, for instance, sounded like a good idea at the time it was developed. It automatically escapes user input so backslashes remain backslashes and not escape characters. A common use of this directive allowed you to insert user-supplied data directly into a database without checking to make sure any embedded quotes wouldn't create unintended SQL statements. While this does guard against SQL injection attacks, you could still end up with garbage in the database. So you still have to check user data to make sure it complies to your standards. This is easier to do before escaping magic characters, so it's better to wait until just before storage; then add all the backslashes you need. Nowadays it's considered good form to not rely on this directive and just use addslashes when you need it.
For maximal code reuse, consider object orientation. But there's a whole chapter on that...
Chapter 2: Object Oriented PHP
"Be lazy," the author writes; "Write good code." One of the ways to organize your code is through object-oriented programming. Most readers know the basic concepts of OOP, and are probably tired of the few over-simplified examples. Beyond that this chapter wants to get you to think OO, to "no longer think about long lists of tasks that a single script should accomplish; instead, [to] see programming as the putting together of a set of tools to which your script will delegate work."
I know my first PHP classes were just namespaced scripts. The attributes and methods weren't at all related. This chapter (as well as Chapter 7 of Volume II) helps you distinguish where your classes are and how they connect. One of the aids for this is the use of Unified Modeling Language (UML) class diagrams. These diagrams, which use boxes for classes and arrows for the relationships between them, are really cool programming and teaching tools that require no code!
Here I think the book's physical workflow got caught in a gap between major PHP releases. The cover says this book says "PHP5 ready," which is a bit of a misnomer because all the code examples and rules are all written for PHP4. Minor text mentioning how things are going to be different in PHP5 has been inserted. It's true that none of the OO code written here will break in PHP5, but there are major additions to PHP5 especially in the OO implementation (no more ampersands! actual private variables! Exceptions! Much, much more!). Still, the author makes the point that you the programmer may not be using PHP5 for a while (PHP 5.0.0 is only a few weeks old today), and that you shouldn't put off learning PHP until version 5 is agreed to be stable.
I've read the comments of PHP bashers, arguing that using it for OO programming is a waste of overhead. The author has heard that argument, too, and rebuts:
"What they forget to mention is the drastic increase in your performance that object oriented programming delivers. After all, fast programmers cost more than fast microprocessors!"
Hear, hear. RAM and disk space are commodities, while programmers are not (yet).
Chapter 3: PHP and MySQLThis goes beyond the simple HOWTO on connecting to a database. A suite of PHP classes is developed for database connections, querying, and result handling, not as much to use as for your "health"--i.e., to see a well-done class from start to finish. For your real applications, use a real, well-maintained and tested class such as those found in PEAR. This is another principle of good programming: Somebody has probably had the same problem you are having right now, and already solved it (also known as Ecclesiastes 1:9, "...there is nothing new under the sun.")
If you've done lots of SQL queries, you get to thinking that there's got to be a better way to access a database. In fact, you can build a layer of abstraction over the database connection layer to create interface classes to individual tables. This is called a persistence layer. For an implementation, see PEAR::DB_DataObject.
Any web programmer fears insecurity, and I don't mean self-doubt. The author weaves discussions of security into each chapter. For instance, you must be careful to guard against allowing users to seriously alter the nature of your SQL queries. Trust no user-supplied data! Also, this chapter gives a PHP-based solution for creating MySQL dumps.
Once you've got the data in the database, making sure users can find it is another problem. You can use LIKE relations in your queries to search field strings. The author shows how to use FULLTEXT indexes (a MySQL 4 feature) to assist in searching the entire table or any set of fields you like, all at once.
Chapter 4: FilesSometimes databases are overkill for data storage, or you need to extract data from text files. The author gives several examples of uses of interacting with a local or remote file system. He explains:
- how to slurp whole files into memory or to process them chunk-by-chunk.
- how to use the PHP built-in functions to interface with the file system (so you can make a self-updating "Last updated: " item on your pages).
- how to use .ini-style files to store configuration data -- a common configuration style which is much faster than keeping it in a RDBMS or XML file.
- how to use FTP with PHP.
- how to compress and decompress with tar through PHP.
- how to send create a file and send it to your web user (custom files generated on-the-fly and ready for download!).
Again, the security threat is raised, and the author gives pointers on how to prevent from crackers getting you to execute their code by including one of their files rather than your own.
Chapter 5: Text Manipulation
When building dynamic web sites, being able to manipulate code is a must. You need to validate the data that users send to you, as well as guard against simple HTML error or malicious cross-site scripting (XSS) attacks. There are lots of built in functions (strip_tags to remove the HTML from a string), but using regular expressions you can validate and filter just about anything. You can reimplement a restricted set of markup tags a la BBCode, or set up a custom, easily-updated profanity filter.
Chapter 6: Dates and Times
Another real-world problem is formatting dates and times in a human-readable
(and perhaps localizeable) way, and on the machine level manipulating dates
correctly. Luckily these are all solved problems and PHP connects you to the C
functions which do it. Whether you store dates as MySQL timestamps (e.g.,
2004-08-03 20:07:00) or UNIX timestamps (1091578114 seconds since the epoch) is
up to you, although if you use the former you'll probably have to convert to
the latter at some point. Putting it all together you can create dynamic
calendars where clicking on a day brings you to your appointments for that day.
Another good use of date functions is a implementation of cron written
entirely in PHP for those not on a unix platform.
Chapter 7: Images
Once you've mastered the art of producing HTML with PHP (developed even further
in Chapter 9), you'll wonder what else can do. It turns out that PHP, using
glue to the GD image library, can output images as well. You can generate
thumbnails of your images to create galleries. You can watermark images with
text to discourage stealing them. You can hide your images behind a PHP script
that protects people other than you from linking directly to your images. And
you can analyze data with enough charts and graphs to make Ross Perot ecstatic.
Chapter 8: Email
Contacting your users off-site is a must if you want them to come back.
Furthermore, it's a nice way to register users by sending them links to an
address they provide. PHP can send email natively using the mail function,
but as always there are nice classes which jazz up the features. You can send
HTML attachments (known by some as "spam", but we're not here to judge), even
including the images in the mail. You can even use PHP as a replacement for
procmail by parsing incoming mail and triggering actions based on headers.
Chapter 9: Web Page Elements
Eventually you get tired of writing HTML, and interweaving markup and
presentation logic can give you a headache. Can't PHP be told to format the
table the right way? Another solved problem! Displaying data in a table is a
common task, and classes such as PEAR::HTML_Table can take a simple data
structure and beautify it for you. Forms are another area in which
PHP-generated code can save you time. You can also use PHP to produce
"breadcrumbs" (there's one at the top of every slashdot page) and drop-down
menus that show your users where in the hierarchy of information they are.
Finally the author shows how to use apache's url_rewrite module to get those
question marks, file extensions, and ampersands out of your URLS and sex them
up. (You can also do this without url_rewrite, completely inside PHP, but
using a custom error document and examining the path requested.)
Chapter 10: Error Handling
So you're all excited about your next web app, and you dive into coding, and
something goes wrong. What then? This chapter is about errors. You can use
the error_reporting function to customize which exceptions actually produce
error messages, or create your own error messages that handle errors your own
way. You can choose to log them in a database, send an e-mail to a coding
team, and most importantly, recover gracefully so that your users don't see an
error message. Not only is it unprofessional, it may reveal information about
your program, file system, or database structure that can harm you.
Appendices
There are several good appendices, which tell you which configuration
directives you're probably most interested in (the complete list you can get on
PHP's web site), some common security breaches, and how to install PEAR, PHP's
version of CPAN. My favorite appendix is the "Hosting Provider Checklist," a
great reference for evaluating whether kewlhosting.com is going to give you the
freedom and support you need to make a great hosted web site.
All in all, I liked this volume. Having read probably a dozen PHP books I wouldn't say it offers new information. But even though you know the plot, it's possible to enjoy a well-told story. See Volume II for heavier-duty ideas.
* My made-up calculus notation for "bang for your buck"
**Like this: http://books.slashdot.org/
In real life, Matthew Leingang is Preceptor in Mathematics at Harvard University. He promises to review any book sent to him for free, and sometimes actually does it. Slashdot welcomes readers' book reviews. To see your own review here, carefully read the book review guidelines, then visit the submission page.
In real life, Matthew Leingang is Preceptor in Mathematics at Harvard University.
If you're that in real life, what is there to pretend to be on slashdot?
"If you think you have things under control, you're not going fast enough." --Mario Andretti
All your base are belong to PHP?
Or...
All your spellcheckers are belong to us?
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
B-side remixes and band commentary.
it's a mad mad word.
there's no place like ~
PHP is one of the best languages I've come across. And I think a lot of it comes from the available library of functions. They're all very well organized, especially in the PHP manual.
I learned PHP by reading the manual, but I found I didn't need a book because it all was very similar to Perl/C, etc.
http://github.com/gbook/nidb
The first line of this story reads 'sympleko (Mattwrites "What a beautiful world anthology is. [...]"'. Having read this I decided to put together a little one-question analogy test for my fellow readers.
For those of you who have taken standardized tests you'll recognize the format of this analogy query:
Acting : Kevin Costner
Editing : _____________
a) Pizza
b) Chrono Trigger
c) Slashdot
d) None of the above.
If you chose answer 'c' you are correct. The explanation for the answer is that in both cases the degree of quality of the first word as performed by the second is diminishing to levels almost incalculably bad.
you can take the road that takes you to the stars...
someone to review a book for me if they can't even bother to proof their own writing?
Yes, anthology is a beautiful world, isn't it?
PHP kicks ASP.
There, I said it.
The preceding message was based on actual events. Only the names, locations and events have been changed.
That would be the rate of change of ! with respect to $. I think simply !/$ is more appropriate.
I'm deeply worried by PHP becoming so increasingly popular.
Can anyone explain this to me, please?
What's so bad about Python, Ruby, etc.?
I have to admit that I'm considered a Python Paladin by everyone around me, but is PHP really an alternative?
Gentlemen, the time has come for a serious discussion on whether or
not to continue using Perl for serious programming projects. As I will
explain, I feel that Perl needs to be retired, much the same way that
Fortran, Cobol and Java have been. Furthermore, allow me to be so bold
as to suggest a superior replacement to this outdated language.
To give you a little background on this subject, I was recently asked
to develop a client/server project on a Unix platform for a Fortune
500 company. While I've never coded in Perl before I have coded in PHP for
fifteen years, and in Javascript for more than twenty, I was stunned to see how
poorly Perl fared compared to these two, more low-level languages.
Perl's biggest difficulty, as we all know, is the fact that it is by far
one of the slowest languages in existance, especially when compared to
more modern languages such as Basic and HTML. Although the reasons for
this are varied, the main reasons seems to be the way Perl requires a
programmer to laboriously work with chunks of symbols globbed together
senslessly.
Requiring a programmer to manipulate unreadable is a tedious way
to program. This was satisfactory back in the early days of coding,
but then again, so were punchcards. By using what are called
"scalars" a Perl programmer is basically requiring the computer to do
three sets of work rather than one. The first time requires the
computer to use a dollar sign to indicate "dollar value" of the scalar. The
second time requires it to perform the needed
operation on this value. Finally the computer must delete the
duplicate set and set the values of the original accordingly.
Clearly this is a horrendous use of resources and the chief reason why
Perl is so slow. When one looks at a more modern (and a more serious)
programming language like HTML, Javascript or - even better - PHP
that lacks such archaic coding styles, one will also note a serious
speed increase over Perl.
So what does this mean for the programming community? I think clearly
that Perl needs to be abandonded. There are two candidates that would be
a suitable replacement for it. Those are HTML and PHP.
Having programmed in both for many years, I believe that PHP has the
edge. Not only is it several times faster than Perl its also much easier to
code in. I found Perl to be confusing, frightening and intimidating with
its non-GUI-based coding style. Furthermore, I like to see the source
code of the projects I work with. HTML's source seems to be under the
monopolistic thumb of W3C much the way that Perl is obscured from us by
the marketing people at the FSF. The GPL "shared source" under
which PHP is released definately seems to be the most fair
and reasonable of all the licenses in existance, with none of the
harsh restrictions of the BSD license. It also lacks the GPLs
requirement that anything coded with its tools becomes property of the
FSF.
I hope to see a switch from Perl to PHP very soon. I've already spoken
with various luminaries in the Perl coding world and most are eager to
begin to transition. Having just gotten off the phone with Mr. Alan
Cox, I can say that he is quite thrilled with the speed increases that
will occur when the Linux kernel is completely rewritten in PHP. Richard
Stallman plans to support this, and hopes that the
great Swede himself, Linux Torvaldis, won't object to renaming Linux
to Gnu/PHP/Linux. Although not a PHP coder himself, I'm told that Slashdot's
very own Admiral Taco will support this on his web site. Finally,
Dennis Ritchie is excited about the switch!
Thank you for your time. Happy coding.
Here are the URL's for samples of the first 4 chapters (so you don't have to give your e-mail address to SitePoint).
m ple.zip
m ple.sit
m ple.tgz
ZIP format:
http://www.sitepoint.com/books/phpant1/phpant1-sa
StuffIT format:
http://www.sitepoint.com/books/phpant1/phpant1-sa
tar/gzip format:
http://www.sitepoint.com/books/phpant1/phpant1-sa
The PHP Anthology - Volume 3 'Return of the Ping'
You don't need a lab to make mud.
try programming a game.
class "monster" can inherit from class object.
object has standard data that pertains to every object in the world, like positioning and physics stuff.
object has a virtual method tick(), so any class that overrides it can process data specific to it. later you can loop through an object pointer array that holds all the objects in your scene and call tick() and render() for each one.
yes, OOP is useful. not required, but definately useful.