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.
Does anyone have links to news/features on what's supposed to be in PHP5? I've been hearing rumors that it's going to be much more object oriented and easier to do serious design work in.
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
Yahoo recently started using PHP to run their site. PHP is not just another toy language to tinker with, its a very capable tool. Don't confuse 'easy to use' with 'not powerful'.
When you make a complete enterprise site, you use the language that will give you the most advantage for maintainability and design.
Exactly. PHP often fulfills that need.
http://twitter.com/onion2k
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...
PHP is a great solution for small to mid size businesses. Designing server based database apps is easy and they can run on Linux/MySql (duh!) which is a great kick in the TCO for a small/mid size biz. While I agree with the earlier flame regarding PHP in the enterprise I do think it works pretty well for business apps just not with thousands of users.
One thing I feel is missing is the ability to USE the host system. If I could access serial devices for example I could have a pc as a database server and one as a cash register, then I could have a serial based cash drawer at the PC being controlled by the server (this is a fairly common POS setup) this would be very useful. (I know I can use Perl to do it)
I've been using php for about 5 years professionally and have actually been looking into using Java, mostly because I'm interested in the concepts behind MVC design.
But one of the things php has given me over the last 5 years is total rock solid stability. I mean, I've hacked up some complete crap code over the years but I've never once had a php related crash(and apache only ever crashed when we tried integrating Cold Fusion into it).
In testing Java servlets I have gotten out of memory errors in a database app I've written, but that could very well have been a lack of knowledge on my part(maybe I had the server misconfigged). I'm reading up more on admining/designing for Java now and will do more serious tests in the future.
But don't dismiss php as a toy language. The code you create can be messy, but it's rock solid stable. 5 years of 80k+ lines of code without any crashes is nothing to laugh at.
Actually, I thought they migrated using PHP for background scripting, not on actual pages that are displayed (I think they still use a proprietary C system).
Of course, this is all out of my memory, not actual links.
Funny thing is, I wasn't gonna start the "J2EE vs PHP for professional site" flamewar, and then someone else goes and starts it.
And PHP doesn't have the greatest OO built in that most architects drool over.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
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...
It depends on what exactly the enterprise size app is doing and what it needs to connect to.
:)
For example, an enterprise wide phone extension list could easily be done using PHP instead of Java.
A complex work-flow application might not be the best fit for PHP. A whiteboard collaboration tool definatly would not either, PHP-GTK not withstanding.
I've used PHP to call both Java and VB COM objects on the same page. I had to work with two different groups in a company, one used Java, the other used VB. It was easier to use PHP than to write a wrapper for either.
"For a successful technology, honesty must take precedence over public relations for nature cannot be fooled." -Feynman
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!
So the book is still up to date, even an entire year after it's release?
Something's wrong here... Those php people better get on the ball and start releasing more often! The only language I know of that's stays that stable is COBOL.
No point in playing with it, unless it's the latest bleeding edge, crashing and burning on a regular basis. On my Windows box, that is - my BSD box remains rock steady.
Nope, still not funny.
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
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.
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
(* Designing server based database apps is easy *)
If you mean data input and query screens, I have to take some exceptions to that. Simple stuff is indeed simple in web apps. However, B-to-B and intranet managers often want GUI-like behavior from browser-based apps, and HTML+JS+DOM can turn into a tangled mess under such demands.
The developer cannot just say, "well, this is an HTML browser, not a GUI, so it will not have all the functionality of a GUI", because that would be a half-lie. With enough effort and spahgetti code, you *can* make it do GUI-like stuff, but the code is usually horrible. The current standards are optimized for e-brochures, and NOT e-biz-forms.
What is needed IMO is HTTP-friendly GUI browsers, using protocols like XWT and SCGUI (I'm still looking into Mozilla). (I rule out non-HTTP protocols because fire-walls often don't accept them. Some protest this, but I don't want to rekindle that debate here.)
There is a huuuuuge need for such in my observation, and no vendor is stepping up to the plate. PHP could still serve as the server-side part of such a system, BTW.
Table-ized A.I.
"And PHP doesn't have the greatest OO built in that most architects drool over."
Actually it has "pretty good" OO. In some ways it has "pretty advanced" OO like mix-ins. PHP5 will have "even more advanced" OO.
Anybody who uses J2EE for a "less then enterprise" web site is just asking for pain. Better to stick needles in your eyes it would hurt less.
If you really want to use java go with webobjects.
War is necrophilia.
- You already have a bias toward Perl, and
- You're talking to Perl experts, which means
- They're probably geeks and Slashdotters
something along these lines should work:OK, I didn't really have anything useful to write. I just like making HTML lists.
We recently switched from perl to PHP. Perl seems to be much better and handling file manipulations and it definitely is more a more complete language. But developing in PHP is so fast that the switch was easy.
.html with cgi-bin/php, all of my pages would still be served fine (although slower if run as a CGI.) What this means is that our layout people can design pages and we can easily put in code after the page design is done to make it look just like they want it. If they then want to move stuff around, they can (for the most part). They can even use editors like frontpage (and it won't complain about the php code if you use the code delimiters.)
With PHP, the default "thing" in a file is html that it just spits out. You have to do something special to make PHP code to run. So if I configured my server to handle
Also, with PHP you can also do things like this:
<? if (somthing) {?
Something was selected
? } else { ?
Something was not selected
? } ?>
so when I am printing out large chunks of html based on some variable, I can just use html without messy prints all over the place. Of course, you can use perl "print EOP" type statments, but I think the PHP approach is more elegant.
Also, the fact that PHP takes care of all the variable collection was a big plus for me. I just type testing.phtml?id=2&name="jeff" and sure enough, $id=2 and $name=jeff. Obviously, you can do the same thing in perl and it's not terribly difficult. But in PHP it is just that much easier and it's one more thing I don't have to worry about.
I would strongly recommend that you at least try PHP for a simple mail form or something. I think you'll fall in love with it for web stuff. And if you're doing database work too, then I think you'll really like it.
I know there are accelerators out there, but most people not know about or use them. Plus I really can't see the harm in including a accelerator in the default engine. Does anyone know why it is not included? There are open source accelerators that can be distributed with PHP.
Many scripting engines eg. Cold fusion, JSP, compile code only the very first time the code is executed since the module was started, then only check to see if the code was changed on disk before executing the already-in-memory code.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Actually it has "pretty good" OO.
..
If I' had modpoints right now, I'd mod this up as "funny"
Any C++ or Java Developer will loose his hair (I he has any left) when reading things like this or this
(the later has nothing to do with oop)
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
It's not hitting the net anytime soon.
PHP 4.3 is still in the midst of release cycles, and things aren't perfectly smooth, as always. Chances are it won't be out for another few weeks (a month or so is probably a safe guess)
PHP5 will be ready... well, when it's ready. Nobody even started thinking what should go into PHP5 yet. Aside from Zend2, which you can use already with PHP4 tree.
If you have a big feature - ask for it, but currently there is nothing that is groundbreaking enough to even start working toward version 5.
Jobs? Which jobs?
This was a decent attempt at a troll, but I feel you could have gone much further with this. You see, the hallmark of a truly great troll is the ability to push something to such an extreme that it greatly offends everybody, even people who agree with you. With that simple principle in mind, allow me to re-format your original post so that it fits snugly into the mold of a great troll.
Ahem...
I learned php a few months ago, but I think I'll stick to perl. If you're making some simple web pages that just need to be marked up, I guess php is okay, but why bother adding a php module to Apache when you've got mod-perl?
Should read:
I learned PHP a few months ago, but I think I'll stick to machine code on the bare hardware. If you're making simple web pages, why bother letting an enormous pile of cruft (like all of Linux) get in your way when you've got all the power and simplicity of machine code available? Besides, who really trusts a big, creaking mass of code put together by a bunch of Communists in Finland?
In Perl, the language helps you, but php just seems to get in the way. Without the equivalent of Perl's excellent DBI/DBD, I don't see much use for php.
You missed a golden opportunity here. Here's an easy fix:
In machine code, the machine helps you by locking up and smoking when you make a typo, but PHP just seems to get in the way by spitting out a bunch of cryptic error messages. Why pollute an already clean error-reporting mechanism (the machine locking up and setting my desk on fire), with a bunch of crud like "Error: Syntax error in line 16", when high-level messages like that only abstract away the true source of the error? Frankly, without the equivalent of machine code's clear and easy-to-understand near and far pointers (on x86, of course, but who really uses that RISC crap, right?), I don't see much use for PHP.
So now, armed with a more complete understanding of the True Way of the Troll, the next time you make a boob of yourself in front of all of Slashdot, you'll do it in a thoughtful, thorough manner.
Arr! The laws of physics be a harsh mistress!
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
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
The links you point out all refer to the fact that php does not act exactly like C++ or Java. Once you actually learn the way php works those particular things don't bother you anymore.
Yes php does not work like C++ or java I don't think anybody is arguing the opposite. I suppose lisp, smalltalk, ocaml, python and perl also don't work like C++ or Java. That's life.
On the other side neither C++ nor Java allow you add methods or attributes to objects at runtime and PHP does. Maybe that's a good thing, maybe not, but I like it and whenever I use a language like java It makes me loose my hair when I can't do it. You have to take each language as it comes.
War is necrophilia.
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.