Slashdot Mirror
Professional PHP4
PHP is an open source server-side HTML-embedded web scripting language for creating dynamic web pages. Outside of it being browser-independent, PHP offers a simple and universal cross-platform solution for e-commerce, complex web, and database-driven applications. Professional PHP4 will show you exactly how to create state-of-the-art web applications that scale well, utilize databases optimally, and connect to a backend network using a multi-tiered approach.
Almost an year since its release, this book has stood the test of time, and proved to be what it promised -- an up-to-date, advanced book on PHP -- a category in which there are very few worthwhile entries to date.
It provides a solid, fast-paced drill on the rudimentaries of PHP (although the fast-paced installation instructions come in the form of classic compendia -- worth 100 pages) for seasoned programmers, before it plunges head straight into the more advanced areas of the language. Each chapter reads a bit like a tutorial on a particular area of advanced PHP development.
If you are a competent programmer in just about any other language or have grappled with HTML before, then this book will teach you PHP from scratch . It will also introduce you to many of the more advanced areas of PHP programming, and is a treasure trove for information on diverse tasks possible with the language.
Notable topics include:
- Object Oriented Programming
- Sessions and Cookies
- Coding an FTP Client
- Sending and Receiving Email and News
- Networking and TCP/IP
- Non-Web Programming (including GTK)
- PHP and XML
- PHP and MySQL/PostgreSQL/ODBC
- Security
- Multi-tier development
- Optimisation
The code for the examples presented in the book is available for download, from the publisher's web site.
Although this book is reasonably complete, it lacks sufficient depth for experienced PHP developers who want to wade into the depths of specific PHP related tasks. Having said that, the publisher has provided information (of course at a separate cost) on specific areas with their second level PHP titles -- Professional PHP4 XML , Beginning PHP4 Multimedia Programming , Beginning PHP4 Databases and Professional PHP Web Services .
Suffice to say that the book has packed together a lot of diverse information (in 975 pages).
Related Links You can purchase Professional PHP4 from bn.com. (You may also be interested in the Slashdot review of Professional PHP XML of a few months ago.) Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
There is a paper on the ZEND engine 2.0 (which will power PHP5)
PDF: http://www.zend.com/engine2/ZendEngine-2.0.pdf
I would put the google HTML version of it, but it seems to be buggered.
I've said it before, and I'll say it again... the PHP website should be enough for anyone with basic programming skills. It's simple, clearly explained, and there's many examples and fixes posted by people. The only thing that would be helpful would be a PHP Cookbook that's as good as the Perl one.
You have enemies? Good. That means you've stood up for something, sometime in your life. --Winston Churchill
yea that why Yahoo is moving to PHP and not Java hmmm and here is slashdot articke about Yahoo moving to PHP
i have worked with both and i PERSONALY prefer PHP, I haven't faced a problem in php that I couldn't have solved....
Who controls the information, controls the world...
I was going to pick up this book, based on the recommondation of friends (programmers) and online reviews, but when I thumbed through it in the bookstore, it just seemed...weak. Thin.
This is PROFESSIONAL PHP programming, not BEGINNING PHP. Why even have the 100 or so odd pages on installation? This book is not targetted at newbies, it is for the serious developer. OK -- you're a J2EE dude who want to check it out; doesn't have PHP installed. Lots of references on the Web, and if you can't find them...you're not a Web developer.
While the book probably would be helpful as a reference in some cases, I was just disappointed in it. The cookie/session section was a joke (and this is new in v4, so should be fairly rigorous).
I didn't buy the book. And I like having references around. I have 7-8 open on my desk right now, from Perl through DHTML to PHP. Oh well, as people have noted, v5 is coming, so I guess we shouldn't get our packets in a bunch...
Thanks for the link. Now I can say, with confidence (from the article):
Yahoo has decided to switch from a proprietary system written in C/C++ to PHP for their backend scripting
Backend scripting != PHP pages on yahoo. This article wasn't read very well by slashdotters. They aren't converting yahoo over to PHP, they are using it for scripting.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Without the equivalent of Perl's excellent DBI/DBD
Like ADODB?
You have enemies? Good. That means you've stood up for something, sometime in your life. --Winston Churchill
I doubt PHP5 will be available any time soon. The 4.3 branch is in a release cycle now (RC3). The Zend engine 2 is very much an alpha work in progress.
I would think a stable release of PHP5 is still quite a ways off.
Mike
Ok ok, I'll be good. Gimme back my karma.
-- Karma whore? You betcha. --
At www.zend.com/zend/week/week114.php
It says:
PHP 5 not yet scheduled The number of messages to the list requesting some sort of schedule or arrival date for PHP 5 seems to be steadily growing. Please note that there are yet no dates for anything to do with PHP 5, and there still may be a whole new PHP (4.4) before the road to 5 officially begins. If there are any announcements to be made you will find them on either the main PHP web site (www.php.net) , or they will be covered here in this summary (I promise!).
You could write the serial control mechanism in perl (or C, or whatever), then use system() (or related) calls from php to poke it / read the output. Not elegant perhaps, but... The other option, since reading and writing to serial ports isn't exactly rocket science or a new thing, would be to grab some C source to do said, and wrap it into a PHP extension (which seems like a semi-easy process from what little I looked at it, if it were truly difficult there wouldn't be bazillions of php extensions). Honestly though, if you start doing hardware access to vital resources from php PLEASE FOR THE LOVE OF GOD make the server machine accessible only on the local lan. In other words, you might want JoeBob the store manager in the back office to be able to have a real-time web interface to moniter the sales line, but you wouldn't want to expose that interface to Dieter the 13 year old German 1337 h4X0r. ;-)
News for Geeks in Austin, TX
Everyone that flames PHP needs to go sit in the corner and remember not to break their magic bubble of personal space. First the slashdot article is about the book not the language, second use whatever works for your needs. If PHP works for you and like it thats wonderful. If not use something else, there's a lot of other options.
I think it depends on what you need your site to do. If all you need is to run database queries and output the results (basically what /. does) then languages like PHP, Cold Fusion, Perl work fine. PHP and Cold Fusion make these kinds of tasks very easy to do and they scale just fine for these types of applications. Where I always run into problems is with applications that require much more...connecting to sockets on other servers to retrieve data and then parse data (XML etc), connecting to booking systems, middleware or mainframe systems, manipulating images on the server that kind of stuff. It seems most enterprise applications end up going beyond what languages like PHP and Cold Fusion can provide without having to write custom tags in C/C++ or Java or something to make up for the shortcomings of these languages. At that point you might as well write the application in J2EE or something that is a little more robust than what most of the web scripting type languages can provide.
In exchange for direct functions to send HTTP headers and cookies, you basically give up the ability to "control" the host computer.
:-)
PHP is not a be-all language, and it'd turn ugly quickly if they tried to force it to be one.
Bear in mind I am meaning access to functions on the server, not on the PC. You may well understand that but these days it can be iffy as to what people mean by host. PHP has a lot of good control functions and a lot of POS apps are run in the browser, hence my example. I feel PHP is rather well suited for that. A lot of people say it is a "perl replacement" to them I offer that if Perl can not do what you need, maybe a new programmer will help more than a new language
I've been using PHP quite heavily for a few years now; I never picked up a PHP book, not once.. Why? Simply because the community support, the IRC channel, the Online Documentation and even places like devshed simply have so much to offer! I have not even once printed or purchased even a mere shred of dead tree painted over with ink that describes or outlines PHP in any way whatsoever.
You can write your own extension (in C for instance) to interface with the hardware - and provide the PHP functions you want.
See here for details...
BlackNova Traders
The 'id=foo&name=bar' translating to $id and $name defined is per the 'register globals' setting, which is now off by default in new installations. You'd need to identify where things are coming from:
$_GET['id'];
More typing, but generally safer, as it does force you to think about where things are coming from.
creation science book
Ah, hopefully grasshopper you will learn in time that embedding code inside your HTML is a really bad idea. Sadly PHP (and JSP and ASP and a whole host of other languages) encourages this behaviour.
What you really want is a good templating system.
(Yes, I know PHP can do templating systems, thank you).
Matt. Want XML + Apache + Stylesheets? Get AxKit.
With permissions set in /dev, you can't access and control system devices such as serial ports? Are you running PHP in safe mode? If so, you'll probably have to disable that.
/dev entries. Unless of course you're using PHP on Windows, then I'm sorry, but you bear the burden of a lower OSform.
I've had only a little experience using PHP to talk directly to devices, but it's been successful experience. I should think you'd be able to pop open the cash drawer and stuff like that on the server with PHP using filesystem functions on
Slay a dragon... over lunch!
With that said, I feel that the top reasons to use PHP rather than perl are:
I realize that most of this won't convert a perl advocate (what would?) especially if they're going to be the sole coder on a project, but that's rarely the case with real production systems.
Related links: Google: php vs perl, Web Automation: PHP vs. Perl vs. PHP
Zend sells it's own accelerator, so it's in their intest NOT to include caching in php, or else zend's sales would drop.
One thing that stirkes about PHP is it's position in the market. It simply ownz all other SSI technologies out there. From ASP over JSP to Cold Fusion, PHP is one of the outstanding successes of OSS.
Yet all these SSI technologies have in common that they still don't manage to really split Design from content. I was all in for PHP as my way of doing SSI stuff until I ran into TAL. It's the second (next to DTML) SSI Language that comes with Zope and has been reimplemented in Perl (PETAL). The essential difference to other SSI solutions like the #1 PHP is that all SSI-relevant tags only come as parameters to standard HTML tags and thus absolutly don't interfere with WYSIWYG HTML tools or other stuff that belongs to markup. You even can get good editors to switch of the non-html tal parameters to do your markup uninterfered. Once on the server content of tal-parametered markup (tal-speak: "mockup") get's replaced with the dynamic content. The point is: Either way you have documents that can be previewed in browsers, edited and formated without the source code for serverside dynamics being touched - or vice versa.
A simple trick to establish true separation of content and code.
We suffer more in our imagination than in reality. - Seneca
I can weigh in on that a little, having first learned and worked with ASP for 2 years before I got in to PHP, and having now been active in ASP and PHP both for that past two years.
ASP vs PHP there is so completely no comparison. There is only one single thing that ASP does that is easier than in PHP, and that is application-scoped variables with out a database. I've written my own PHP classes to facilitate this, and although they may not be as efficient as ASP's memory resident access, they are just as useful.
The hugely wide variety of functions PHP provides make programming a delight where you work more on your programming concepts and code flow than on authoring code. There are simply hundreds of functions available in PHP that I use on almost every page, that would require custom-written functions (that thus run as script, at lower performance than the precompiled PHP functions) that are simply not available in ASP. Try to do a join() or split() in ASP. Yes, it's doable, but with quite a lot of legwork. How about regular expressions? Searching, replacing, replacing with code execution, and more? Not gonna happen in ASP, nope.
Then there are SIMPLE things that are HTTP standards that are simply lacking in ASP. For example, uploading a file. Gotta buy a plugin in ASP to do that. Or uploading creating an array of elements on a form. If you want to have an unknown number of entries in a form, in PHP, you can name the input fields, "field[0]","field[1]","field[2]" and they come in as an array. Or you can even name them "field[]","field[]","field[]", and they will come in as an automatically indexed array. Useful when you want to do things like add rows of input to a table with javascript, and have a script that easily handles the collection. Try to upload an array in ASP, and you have to write code that breaks down the field names to your liking.
There are so many functions that I take for granted in PHP that I now have my own library of PHP functions rewritten in ASP so that when I am authoring in ASP, I'm not as limited by the language. Just try to do an md5 in ASP, or any other cryptographic operation though, I dare you.
Ok, sorry, rant over, been working on an ASP for the past month solid, and I think I'm going through PHP withdrawl.
Slay a dragon... over lunch!
performance wise, i think perl and php are on the same level
... and let me tell you - its major pain.
i started out with php and then slowly moved to perl. i still have a lot of apps in php that i have to manintain once in a while
php is really easy to learn and implement, but it lacks infracstructure. on the other hand, in perl you get away with a lot more things and its true that if you are not careful perl will get obfuscated and unmaintainable very fast.
beauty of perl comes in when you put effort into developing strong infrastructure and stick to it. always use strict, -wt (warnings and taint mode). organize your code into neat modules (CGI::Application) and use a templating system (HTML::Template is very simple and wont let you clutter html with code). note that php doesnt have any of this features as readily available as in perl through CPAN modules
when it comes to documentation, it might be true that php has good resources online, but perl has a lot larger comunity (check out perlmonks.org) i got replies on my questions within 30 minutes of posting!
in short... perl has superior architecture to php, however php has better corporate support and better learning curve
A rough outline of the way it works goes like this, you make your SQL schema and load it into your database, then you point DB::DataObjects at the database and it generates class wrapper files for each table. This by itself isn't fantastically useful, if you were just writing PHP the difference between using the class and using the DB PEAR stuff directly is pretty minimal, however its when you bring smarty into the picture that things get interesting.
The reason is primarily because you can then pass the object you've retrieved from the database straight to smarty without thinking about it, within your template you can acccess the properties (Although not the results of methods, much to my dissapointment) directly, so *your* code doesn't need to worry about it, which means any time you want to add a new field to a table, you just add it in the database, run the dataobjects create script and then plonk it in the template, and it Just Works.
The DataObjects create script is pretty smart, the class definitions that it generates are marked up with comments that give you flexibility to customise the class without risking the modifications getting overwritten next time you regen.
Leaving you with only the "glue" PHP in the middle to write, the bit that handles logins, decides what functions need to be called to do what, and what page to display at the end of it. Believe it or not, smarty comes to the rescue here as well, giving you a simple mechanism to split up your logic and display operations.
One of the primary problems with a PHP script is the switch statement. In the begining, people didn't give a rats about decent user flow, so every page was a different PHP script, and this worked fine except in the case of error conditions or multi-operators, ie, ok, I've just added the user, but now I'm stuck in add_user.php and I want to send them back to list_users.php. Some particularly object oriented people managed to get around this by having everything in classes, but it really didn't work well.
Then came the switch statement, in the switch statement, everything effectively was in index.php, sure we had a lot of includes, each of which did a fairly specific thing, but in the end, all requests went to one script, and specified a mode or op or sequence or whatever you want to call it. This variable determined what was to be shown (ie, op=add_user), then, when add_user was done it'd call the list_user op equivalent somehow.
The issue here was that the switch statement rapidly became the debuggers worst nightmare. Without a decent templating frontend, PHP and HTML became mixed into case blocks, includes were all over the place, and the amount of state to track mentally in any given place was horrendous. Decent programmers utilised standard methods to reduce the clutter but it still never really felt clean, go check out a lot of the PHP scripts available on the web these days to see what I mean, its pretty common.
Another, small subset decided to use url redirects and the multi-file approach to resolve the same issue, they had the same problems but just confined to particularly ugly URLs and lots of page reloads.
Recent advances and ideas have left us with a lot more options. Those who are still heavily OO are still running fine, they're not developing that quickly, but their code is ok, some of the more abstract programmers are doing ok on a task-by-task basis, developing entirely new structures as appropriate to the problem, but again, development time is the cost, and often a lack of code reuse means a lot of debugging.
The MVC model is of course entirely appropriate to the particular problem, and what I suggest here is basically that concept although not explicitly.
The idea essentially, is that for any page displayed, there are a number of actual "atomic" operations that need to be done. For a login page perhaps there are none, its just a damn login page. For a user edit form, there is the retrieval of the users details (and possibly a permissions check), for the page that actually does the update of the users details, there are the permissions check, the update, possibly the display of the original edit form with details filled in an an error message, or possibly the display of a user list with a message indicating the edit was successful.
Always, at the end, we display a page of some kind, and we never do anything after that.
We also never display more than one page, we might decide between two but we don't show more than one.
Thus I construct my PHP apps like this:
- Require in DataObjects, Smarty, misc
- Initialise connections etc
- Retrieve session details if possible, otherwise get Guest user
- Define functional units, functions whose task is to *do* something. If these functions have anything to output, they $tpl->assign it into the template store, if they run into an error condition, they call the relevant display unit with the error message
- Define display units, these act as wrappers for the $tpl->display() call, displaying a particular template with all the data gathered so far
- Define the sequence switch, this is a switch statement on a variable, each element of the case blocks is *only* function calls, to any number of functional units, and finishing off with a display unit. Nothing else, just that.
The end result? you have a list of operations, a list of pages, and a nice clean set of instructions on how to put them together. It is possible to extend this to handling error conditions in the sequence switch however without exceptions (coming in php 5 w00t!) you're likely to find yourself wasting a lot of time trying to come up with an error passing routine, I haven't found a real downside to just calling the display functions directly in case of error.The biggest benefit of this method is pure speed, you can develop small bits of functionality quickly within the framework, you can string them together arbitrarily for various combo pages (assuming you've been careful with your template namespace) and late additions can almost always be handled gracefully with a minimum of effort.
Phi.
I won't get into PHP-vs-Perl, as I think the two complement eachother nicely (if you realy know how to use mod_perl and PHP, you can do some amazing things with the Web which are not idealy suited to either one).
However, you are incorrect on some points:
Outstanding database support. PHP supports virtually every DB under the sun (although Berkeley DB is missing, oddly enough.) Perl seems limited to MySQL and PostgreSQL, and its really a kludge for the later. I've heard that this will be fixed in upcoming versions of Perl though.
Since version 4 (over 10 years ago) Perl has had access to Sybase and Oracle. Newer additions (from the past 5 years or so) include MySQL, PostgreSQL, CSV flat-file DBs, DB2, *DBM, and an ODBC interface layer for just about any database.
The DBI module provides one uniform interface to all of these.
Speed. PHP is one of the fastest languages I've ever used. While it won't be replacing assembly or C, its definitely faster than Perl in most cases.
This depends wildly on what you're doing. PHP is pretty slow when it comes to handling deep, and complex data-structures, but quite fast when it comes to handling simple data like strings. Perl maintains a balance between these two, and an elegant interface to C and C++ for applications which need to speed up critical sections of code.
Portability. I can take PHP code off my Linux box and plop it onto an IIS server, or even one of those new Macintosh servers and have it run without having to change a single line of code. Try doing this with Perl! Its as though it was written in assembly, Perl requires that much rewriting.
My Perl programs run on Windows, MacOS/X, VMS, all UNIXen, and many other platforms. Dunno what you've had trouble with, but I suggest you may have had trouble with Perl because you were not familiar with it.
Graphics. PHP comes with a nice little graphics library. While I wouldn't use its to code the new Doom (VB would be a better choice!) its adequate for most web pages, and should be considered as a substitute for Flash for certain things. Perl lacks a graphics library of any kind.
This is so wildly untrue, it's amazing! Perl has some of the most comprehensive graphics handling possible. From OpenGL to the GD module to PDL, Perl can do anything from complex scientific simulation graphics to simple 2 and 3-D charts and graphs to line-drawing. PDL requires special note. It's a library for dealing with arbitrary binary data in a number of ways from performing vast arrays of numeric transformations (e.g. Fourier Transforms, and other matrix transformations) to rendering graphics to modifying image data. It's a god-send for the scientific community that previously had to deal with proprietary systems that were of dubious value given that they could not be modified.
There's even a comprehensive interface to The Gimp, which I wrote an article on for The Perl Journal.
The Perl resource that you probably are not aware of (based on your comments) is the Comprehensive Perl Archive Network (CPAN). There is a module list that gives you a nice index of everything that Perl can do that is not shipped with the binaries. Perl also provides a CPAN module that can be used to automatically download, compile and install anything from CPAN.