Programming PHP

dooling writes "Continuing the tradition of well written O'Reilly 'Programming' books by those who know the language best, Programming PHP, co-written by the creator of PHP, Rasmus Lerdorf, provides a detailed overview of the popular PHP web-page scripting language. This book provides good programmers who have never used PHP enough information to do serious web development using PHP and serves as an excellent reference for web-page designers who dabble in PHP." Read on for the rest of his review. Programming PHP author Rasmus Lerdorf & Kevin Tatroe pages 507 publisher O'Reilly and Associates rating 7 reviewer dooling ISBN 1565926102 summary great PHP book for serious programmers, good reference While not as entertaining as Programming Perl, it isn't nearly as long either (and doesn't have to be). The book is written in a straightforward style and is very well organized. Appendices provide quick reference to all the PHP built-in functions and many PHP extensions. The most popular extensions, e.g., PEAR DB (database connectivity) and XML, have entire chapters devoted to them. Can't find a PHP extension for your favorite library? There's a chapter about writing your own PHP extensions, including writing C library wrappers.

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 Links

• PHP home page
• Rasmus Lerdorf's home page
• Kevin Tatroe's O'Reilly page
• O'Reilly page for book
  

See 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.

Comments

PHP Security Papers

[Anonymous Coward]

www.cgisecurity.com/lib

Contradiction in Review

[hether]

Isn't this a contradiction:

This book provides good programmers who have never used PHP enough information to do serious web development using PHP

and

so if you want to use PHP but have never written any serious code, you may want to look elsewhere for an introduction

So is it good for newbies or not?

Re:Contradiction in Review

[alnapp]

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

Re:Contradiction in Review

[Grey Brick]

Good for newbies to PHP, not newbies to programming.

Re:Contradiction in Review

[Spazholio]

It's not a contradiction. It basically says that if you've ever written (good?) code, not necessarily in PHP, this is a good reference to get you introduced to the nuances of the language. However, if you're a total neophyte, and have never written code in any language, then this would not be the way to go.

This book is destined to become a classic

[PhysicsGenius]

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".

Re:This book is destined to become a classic

[OmniVector]

This THE definitive php book. it is so definitive, it redefines the definition of what definitive means.

Re:This book is destined to become a classic

[sehryan]

Shouldn't that be:

while ($havingSex) {
if (!$protected) {
$numChildren++;
$arrChildNames[$numChildren] = "PHP Programming " . $lastname;
}
}

Re:This book is destined to become a classic

[Dukhat]

PHP is a widely used embedded-in-html scripting language, but it is by no means the first. PHP started off as a templating language, but features were continually added which it caused it to grow beyond Server Side Includes. As such, PHP is not a well designed scripting language. If you separate your code into functions, it is extremely difficult to track down errors, because you only get the line that the error occured on and not the line that called that function.

PHP is definitely very easy to start programming dynamic web pages, but it is
increasingly problematic as your code base grows. If you primarily do web
design and just want a little dynamic content, PHP's shortcomings won't affect
you. However, web based applications will run into problems with PHP
repeatedly. Besides the problem where it copies objects out of an array
when you use a "foreach", you are also stuck remembering to put an amperstand
in front of every object so it gets passed or assigned by reference and not
value.
For example:
$x = $obj; # $x is a copy of $obj
$x = &$obj; # $x and $obj refer to the same object

Besides the overhead of copying large objects, it just creates one more
"gotcha" that you have to remember to avoid. It is not that good code can't
be written, but it is so much easier to write problematic code.

Other projects for embedding scripting into HTML:
http://pmz.sourceforge.net/

http://webware.sourceforge.net/
http://www.kryogenix.org/code/castalian/

http://www.zope.org/

http://aspn.activestate.com/ASPN/Reference/Produ ct s/PerlEx/Embedded.html

Re:This book is destined to become a classic

[ealar dlanvuli]

Wtf, he's not a troll..

I almost added him to my friends list on several occasions. I find his posts at least as insigntfull as the average /. post, and quite often he is funny.

Try posting non-AC when accusing someone of being a troll.

Re:This book is destined to become a classic

[JabberWokky]

while($havingSex and !$protected)
$arrChildNames[] = "PHP Programming ".$lastname;

How about that?

--
Evan (no references - I didn't use an &)

No contradiction

[l-ascorbic]

This book provides good programmers who have never used PHP enough information to do serious web development using PHP

Those who are experienced with another language will find this book useful for picking up PHP.

so if you want to use PHP but have never written any serious code, you may want to look elsewhere for an introduction

..if, however, you don't have experience in any programming language, you'd be best to find a book that spends more time covering coding basics.

Re:how relevant is PHP today?

[onion2k]

According to NetCraft, there are more PHP web sites than ASP.

Useful, but not necessary

[$rtbl_this]

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...

Re:Useful, but not necessary

[JazerWonkie]

I agree completely with you. And to append on to what you said. Most books that come out on PHP are already out of date as far as the all the new functions that PHP has. This isn't a rib on the writers of the PHP books, it's just because of the time it takes to write the book, go through the publishing process and get the book shipped.

By then new functions have come out and the book that was supposed to cover PHP is now obsolete.

And again as much as I respect the writers and publishers of the PHP books, I find my times the comments below the functions on php's website to be more helpful than any book.

Re:Useful, but not necessary

[fungus]

I used to read documentation with my laptop while in my bath. Way cheaper than buying those dead tree books.

I thought it was a good idea until I had to call tech support and they told me that it was not considered 'normal use' for the warranty. It only takes tech support people to say that taking a bath/shower is not normal I guess.

Re:Useful, but not necessary

[iomud]

If only all documentation was as good as the php website. Seriously it's fantastic, other languages should follow in it's example. I think it's a big factor of php's success myself. Recently I had some questions about apache 2 and php, I asked them on opn in #php and who answers me but rasmus himself. How cool is that? (Ok it's irc.. it can't be that cool but you know what I mean)

Re:Useful, but not necessary

[RadioheadKid]

I totally agree. Usually if the manual page on the website doesn't answer my question, someone in the comments below has either answered it, or provided a working example, which I guess is probably the same as answering it, or maybe not, or umm..well you get the point.

Re:Useful, but not necessary

[Huge Pi Removal]

Yeah, but how hard is answering a question on PHP and apache 2? The only 2 possible answers are "It might work" and "It doesn't work".

:-)

Re:Useful, but not necessary

[JabberWokky]

The two best documentation sites I've seen are PHP and Qt's. I wish there was a good html reference site - w3c's and Netscapes don't document IE's irregularities. Nor does MSDN's (which is my favorite), although it at least documents Netscape's quirks.

Anybody else notice that IE has a slew of undocumented, functional tags? <image> for instance.

--
Evan (no reference)

Re:Remote Object Calls.

[ctembreull]

This is true... and not true at the same time. I work for a large company (name withheld). We use it here, and quite successfully. I also worked for a large company prior to this one. We used it there, as well.

Lacking x feature or n widget doesn't necessarily stop businesses from using something, it just keeps them from using it for everything.

Re:how relevant is PHP today?

[caldroun]

Are you kidding?
I work at a law firm full time, and that is all we use.
PHP is all I get requests for now, for outside work. (Actually less and less ASP crap, and no Cold Fusion)

PHP reference

[ProfitElijah]

While I am sure that this is an excellent reference for PHP users, I'm sure I'm not the only one who thinks there is little point in buying a book on PHP when http://www.php.net/manual/ exists.

Re:PHP reference

[mackstann]

there's certain things that you just can't learn with a manual, like the chapter on OOP, or the chapter on security, etc etc. then again if you already know these things....

Re:PHP reference

[reallocate]

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.

Re:PHP reference

[lou2112]

i would agree. even though i own the book, i find that i consult the online manual before i do the book. the user comments and more timely updates there make it more worthwhile. if you develop remotely (without 'net access) or if you strongly prefer a book to a site, i recommend this book above any other book on php. however, with a manual as concise, coherent, comprehensive, clear, and consistent as php's, there is little a book can offer without doing your job for you.

thanks for the link

[jon_c]

Though i'm not sure how they got those numbers it does show an interesting trend. PHP has been on the decline this year.

Also this doesn't relate well to other non-apache based tech's like ASP or ColdFusion.

-Jon

Re:thanks for the link

[ceejayoz]

Their stats show the same trend in just about every Apache module except Perl. I suspect it's due to the recent slump in the economy sinking dot.com and other businesses.

Also, Netcraft's survey shows steady increase in usage.

Re:how relevant is PHP today?

[NineNine]

I see ASP a hell of a lot more than I see PHP in my area.

I saw this

[asv108]

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.

Re:I saw this

[Tablizer]

but I figured that there is probably very little in the book that PHP's excellent online documentation [php.net] doesn't provide.

I find books generally easier on the eyes than monitors. If I am going to be spending a lot of time with a language, then books make nice additions at times. Plus, you can read the book while waiting for somebody at the airport or the like.

Re:I saw this

[wdr1]

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 [php.net] doesn't provide.

A few folks have said this, and I agree the online documentation is very well done.

However, another way to phrase this is:

Language authors beware! DO NOT CREATE GOOD, FREELY AVAILABLE DOCUMENTATION! Doing so eliminates the need for books, etc. and thus elminates the only major source of revenue!

Come on, guys. If you like the online documentation, buy the damn book too. For crying outloud, put some money in the pockets of the folks working hard to great things for you. I haven't cracked the spine on the 3rd edition of Programming Perl since I bought it (since perldoc perl is so well done), but I still found it worth buying because I wanted to continue to support the authors (who are all active developers in the Perl community).

-Bill

Re:I saw this

[Rasmus]

Do you really believe that this was my plan? And even if it was, do you think I succeeded? The online docs are freakin' excellent if you ask me, and I will be the first to tell you that you do not need to buy the dead-tree O'Reilly book in order to use PHP. Some people just like having a book they can sit and read on a train, plane or a beach without squinting at a screen. Plus, you don't look like such a geek if you are lying on a beach with a book vs. lying there with a laptop.

You probably also don't know the financials of publishing all that well. Trust me, this book is not going to make me rich even if every PHP user out there bought a copy. Keep in mind that my name is not the only one on this book. Hopefully it will cover various PHP-related travel expenses I always end up with going to conferences and user group meetings and also help with a computer upgrade and if I am lucky a fancy new laptop.

Re:I saw this

[mattman]

Hi Rasmus! Good to see your name after almost ten years since UW. I've been following your success with PHP from a distance and I really do mean to learn it sometime. Maybe this book is a good chance to do just that. Matt Manuel SD93.

CORBA?

[mgkimsal2]

I could have sworn there was CORBA support (able to compile in CORBA support, anyway) but I can't find reference to it now. Has it gone?

Re:CORBA?

[ceejayoz]

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?

Re:CORBA?

[SirSlud]

I believe there is a CORBA module, but I have no idea how far along it is. It was non-functional when 4.0 came out. No idea where it is now.

Developing custom modules for PHP in C is pretty easy - I dont imagine it would be too tough to write a custom module that could provide PHP-level function calls that resulted in CORBA calls being made across the wire (I suppose you'd have to use a C Orb .. ORBit would be a natural choice, although my only CORBA experience is C++ with omniORB, so YMMV .. then again, maybe you can write PHP modules in C++, I'm too lazy to think about this. :)

Re:CORBA?

[SirSlud]

Aha! Thanks for making my post redunant!

Yes, google is great, but laziness is better. ;)

I do recall us having some difficulties with ORBit a year or so ago (bug related issues, they might even be fixed today for all I know) so a module that could be compiled against different ORBs would be ultra cool.

Re:CORBA?

[mgkimsal2]

Google's great, but there's no mention of the CORBA support on the PHP.net site, and there used to be (satellite extension I think it was referred to as). It's not there anymore from what I can see, which is what I was referring to.

Re:CORBA?

[loginx]

If my memory is correct, you will find what you are looking for at pear.php.net
The ORBit project moved there.

Re:CORBA?

[GOD_ALMIGHTY]

IIRC, ORBit isn't a real CORBA orb in that it does it's own method of authentication and deviates from the Open Group Standards in other ways. I've always gotten the impression that the purpose of ORBit was to provide GNOME with a component messaging architecture rather than actual CORBA capabilities.

You'd really want an abstraction to which you could write your PHP code that would deal with any CORBA x.x complient ORB, then you could have modules for each ORB, like the way database stuff is abstracted in JDBC or DBD. This is one of the reasons I think enterprise apps shouldn't be written in PHP or PERL. Java provides a really good framework for these sorts of services. There are Java bindings for a lot of ORBs, RDBMs, LDAP servers, that are part of an abstraction and allows you to write code that can utilize any driver that is written for the abstraction.

But, to each his own I guess.

Re:how relevant is PHP today?

[NineNine]

Netcraft knows nothing about intranets, which is where most real web development is done. I have yet to see a large company standardize on PHP, internally.

Alternate Resource

[TheFlyingGoat]

I've always found php.net to answer all of my questions very effectively. The online manual has everything a manual should, plus additional comments from users. The comments contain everything from hints about how to use a function to complete code samples. Many other programming languages could benefit from similar sites.

Re:how relevant is PHP today?

[cscx]

Tell me about it. PHP is good if you are running a small MySQL-based webzine but if you're doing e-Commerce or anything database-intensive, as most high-volume sites show, use ASP, JSP, or precompiled-binaries (in the case of eBay's ISAPI interface).

ASP is for people who don't mind paying for a good programming environment.

Re:how relevant is PHP today? [OT]

[morgajel]

That's very interesting... where approximately are you located? I'm in the Grand Rapids area myself, and all I can find as a web developer are asp gigs. I'd much rather use php and am generally interested in any area that would be looking for php developers,

Buy the book

[The Ape With No Name]

and help pay Rasmus for his PHP, which is pretty cool. He gave a great tutorial at our university and parked PHP development all over the place. I love Perl like Madonna loves dick, but PHP is a good tool to have in the carpenter's box for many one-off projects and tasks that simply don't require Perl.

The "X doesn't have Y" syndrome

[Pac]

No, nothing has everything. On the other hand, "business" will do without almost anything as long as the task at hand gets done. PHP is not only excelent for business, it is wildly used in large e-commerce sites all over the world. Along with Perl, Python and Java servlets, it is one of the key web development technologies. It is very fast and very responsive. The lack of one or other feature may be a local problem, but it is not a general problem that allow you to classify it as "pointless"

Only inexperience makes one mix the "must have" column with the "nice to have" column. Or excessive press release reading. I have been using Java (Tomcat) and Python (by the way of Zope) in my recent projects, but I used PHP for years and it has always been adequate for small and large projects.

Re:Remote Object Calls.

[sporty]

What makes it worse is they are trying to make it more OO by re-inventing the wheel. If they used an OO language underneath, they can make it more OO like.

PHP always acted like a complete hack of a language vs something that was engineered. Look at the database layer? No common functionality. Pear is cool and all, but by making the old calls avail, you allow users to still shoot themselves in the foot.

Sorry, bitter from trying to do enterprise programming with it.

Tip

[Permission Denied]

PHP's online documentation is excellent. Their website has this very useful feature where you don't even have to have a window open to it when you're doing web development: simply type in the name of the function you want:

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.

Re:Tip

[Dr. Smooth]

even better -- use Mozilla bookmark keywords; I only have to type

php shm_attach

to get the documentation on the shm_attach() function. Mozilla and PHP rule!

Re:Tip

[loginx]

Even better, if you're using mozilla, you may want to try "EasySearch", which is kind of like the google toolbar but you can setup your search engines to google groups, php.net, ebay, etc...

And I agree, I use the php.net's search from URL all the time...

http://www.php.net/function_name will not only show you the manual for function_name but will also launch a full search on the whole website if it didn't find the appropriate function...
I wish google had that...

Re:Tip

[JabberWokky]

If you're running Konqueror, simply type urls of the form php:ob_start. Or, if you're using KDE as a whole, just hit Alt-F2 and type php:print_r or whatever you want. If you need general information (i.e., you don't know the class or function you need), simply do php:xml or php:file uploading.

--
Evan (no references)

Is this neccesary?

[n-baxley]

Is a PHP reference book really neccesary? With the excellent webpage they have I just see a book becoming outdated too fast. The only useful one would be the pocket reference edition of this book which I have but still use seldom.

Re:Is this neccesary?

[budcub]

Everyone seems to be chimming in with "don't buy it, read it online". Am I the only person who can't stand reading books online or following online directions? I like to have a book open on the desk next to me while I'm trying something on the computer in front of me. I can't stand searching through a webpage when I can put a few post-its and highlights in a book and have the info just as fast, if not faster.

Re:Is this neccesary?

[Jobe_br]

You're not alone, not by a long shot. Having an online reference is priceless (especially one edited by the users of a particular technology), but having a dead tree version is equally priceless. I'd hate to develop without either.

Re:Is this neccesary?

[reallocate]

Don't fret, you're normal. Reading book-length material online is a real pain (literally).

The "this book isn't necessary" chatter appears everytime /. runs a book review. (Why even ask if a book is "necessary"? That's not germane. A book is here because an author wanted to write it and a publisher bought it.) Some posters seem to take a book's existence as an affront to their personal image of the Universe. The rest can't seem to tell the difference between a reference book and something that might actually teach them something.

phew, get some soap

[DrSkwid]

taking a bath/shower is not normal

Try a "Magic The Gathering" convention

I reviewed this months ago

[truefluke]

I have also given a 'quickie' review about this book months ago on out little site. You can also find the thread on signalnine by clicking on the 'reader reviews' link, on the book information page.

register_globals

[prof187]

i love php, it's what i program in all the time
but this decision on their part baffles me. why would they wait so late in development to remove register_globals as an option that can be turned on. i imagine that many people won't update because of this. and the ones who do may find some scripts not working. it seems that they should have made this decision a while back.

i know you can still use $HTTP_*_VARS w/ it turned off, but scripts that are using $username and $password from forms are going to be screwed, barring a cheap loop at the beginning.

Re:register_globals

[illogique]

why would they wait so late in development to remove register_globals

because it's so hard to change people mind!!

and it was a cool feature before knowing the security issue...
and use $_* superglobal, they much cooler than $HTTP_*_VARS (except that they work only in php>=4.1)

Re:register_globals

[prof187]

yeah, i *try* to write any new scripts for any environment by doing
if(!is_array($_*){$_*=$HTTP_*_VARS;}

and oh, i know about changing people's minds, ugh...we recently changed from pegasus mail (ick!) to a web based mail. well, the complaints haven't stopped from a certain group of people who just...want...to..stay in the past. here's one of their arguments, "don't give me a bmw when all i need is a ford"

Re:register_globals

[ceejayoz]

It's simple to re-enable register_globals - just use ini_set() or make a .htaccess file.

Not good practice, but can certainly do it if needed.

Re:register_globals

[thinkninja]

what in god's name are you talking about? i figured that perhaps they had removed register_globals in 4.2.3 so i just upgraded. (un)surprisingly it's still there.

besides using the superglobal arrays is more secure and good practice. but if you can't work without them change your php.ini or..

ini_set("register_globals", "1");

Re:register_globals

[loginx]

Or you can simply use the following code:

import_request_variables("GPCS"); at the beginning of your script or even better, include file, and all your request variables will be imported from the $_* arrays right into the global scope.

In this example, it will override in the following order:
Get, Post, Cookies and Session.

Re:register_globals

[prof187]

oh really? i hadn't noticed that it was still there...

i know it's more secure, nowhere in my comment did i say that *I* use those. granted, i used to back in the day, but once i learned of the security issues (and less global cluttering), i changed.

Re:register_globals

[justMichael]

You are half correct...

Please note that register_globals cannot be set at runtime (ini_set()). Although, you can use .htaccess if your host allows it as described above. An example .htaccess entry: php_flag register_globals on.

Taken from the manual

Another workaround is this:

if (ini_get('register_globals') != 1) {
extract($_ENV, EXTR_SKIP);
extract($_REQUEST, EXTR_SKIP);
extract($_SERVER, EXTR_SKIP);
}

Re:register_globals

[thinkninja]

yes, it's in the changelog of 4.2.0
ini_set(); sets the configuration option for the scripts duration and then restores when the script is halted.

Re:register_globals

[chiller2]

I must admit I thought this would be a pain at first, but you do get some breathing space with being able to register_globals in the php config until such time as you've either upgraded the old style code. The new system is much better. Plus reading/setting your session variables can be done in the same way.

$_SESSION['somevariable']="blah";
echo $_SERVER['REMOTE_ADDR'];
echo $_GET['pageno']; ... and so on.

chiller2
------
LoHost - www.lohost.com - dev hosting accounts with smtp auth & mysql root access

lol

[DrSkwid]

ASP is for people who don't mind paying for a good programming environment.

Give me the unix programming environment before any version of Visual Studio.

It's been a while but last time I used IIS & ASP you couldn't even open a socket.

Re:lol

[NineNine]

If your web application has to manually open a socket, then you completely screwed up the architecture, somewhere.

Re:lol

[cscx]

IIRC, ASP does not allow direct sockets access for security purposes. If you really want to manipulate connections like that, write a server-side ActiveX Control. That's the "right" way to do it.

Re:lol

[DrSkwid]

have you ever developed server side activex controls?

I have on nt4sp3 IIS4. Version Control Nightmare it was. Change a line, compile, (reboot|change the vbscript & have 20 slightly different versions in memory at once).

So how is writing an active x control to do sockets more secure again?

I'm not sure my hosting company would be too keen on me doing binary installs on their IIS Server.

Anyway. That was the last straw. Never touched IIS since. FreeBSD & plan9 all the way now :)

Book vs. online manual

[mgkimsal2]

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/). :)

Re:Book vs. online manual

[Stuart Gibson]

My personal favourite is the Windows help version of the PHP manual which DOES include the user comments if you get the right version. Since there seems to be nearly as much activity surounding the production of this version as there is of PHP itself, it is well worth checking regularly for updated versions. If you're working offline, this is much better than any book can ever be. Like PHP, the Windows help version is wonderfully designed and easy to use.

Goblin

ASP

[Pac]

You have probably never used PHP seriously, so you can be forgiven for your fast words. PHP is used in large commerce sites and large content sites all over the world.

Actually, ASP is for people who don't mind being locked in one operating platform, a problem PHP, Java , Python and Perl don't have. For your small projects it may not be an issue, but as projects grow bigger and more expensive, flexibility (pointedly cross-platform) quickly becomes a fundamental issue.

Re:ASP

[NineNine]

Again, commerce sites are, by definition, simple, low volume applications. Content sites are even more lightwieght. Those are 1. no test of a language and 2. irrelevant as far as the job market is concerned.

One platform isn't a problem if the project is thought out and architected correctly. If you're jumping platforms midway through, somebody did a real half-assed job in the planning phase.

Re:ASP

[cscx]

Actually, ASP is for people who don't mind being locked in one operating platform

ASP runs on Windows, Solaris, and Linux. That's three.

Re:ASP

[cioxx]

ASP runs on Windows, Solaris, and Linux. That's three.

Add *BSD to that list also. But of course you cannot run ASP 2/3.x w/o ChiliASP when dealing with non MS OSes.

Re:ASP

[cscx]

I believe that ChiliASP! ships free with Solaris. Any truth to this?

Re:ASP

[cioxx]

I believe that ChiliASP! ships free with Solaris. Any truth to this?

Yes, you can obtain a free copy of ChiliASP only if you're running Sun ONE Web Server. I'm not sure whether it comes bundled, since I haven't used Sun One which used to be called iPlanet. But then again, you're still paying for the Server.

Re:ASP

[Lordrashmi]

My experience with ChiliSoft ASP was that it really really sucked.... Of course that was a while back so it might have improved by now.

Re:Remote Object Calls.

[einhverfr]

Well, there is XML-RPC support as an extension (experimental) and there are several XML-RPC and SOAP classes available written in PHP.

I am writing a major web tools framework (see my sig), and I will be adding SOAP hooks for the applications as a whole and a SOAP engine as well (once the sample app is rewritten to be OO).

Re:Remote Object Calls.

[Azghoul]

What a pathetic, arrogant attitude. Think /all/ businesses need remote calls? Think again.

Thinking more broadly, the vast majority of people in the U.S. work for small companies, and they certainly don't need super-mega-EJB-whatever huge technology is in vogue this week.

I think, beneath your silly comment, I'd suspect you'd admit you're in the "best tool for the job" crowd. But don't assume everyone's job is the same as yours.

ASP suxors

[The Ape With No Name]

e-Commerce sites use ASP because they are developed by DBAs who are usually not programmers, but drag-and-droppers who understand control structures. It has nothing to do with the "intensity" of the work. Perl and Oracle are just as fast if you know what you are doing. Spank you very much, Trolly Trollerton.

Re:ASP suxors

[cscx]

ASP + Oracle is even faster. Trust me, I've used it.

Re:ASP suxors

[Tablizer]

(* ASP + Oracle is even faster. Trust me, I've used it. *)

Who says that you can't use PHP + Oracle?

To OOP or not to OOP

[killmenow]

When I read your post, I thought of C++...

A complete hack of a language. It's cool and all, but by making the old calls available, you allow users to still shoot themselves in the foot.

At any rate, I always thought the point of a good programming language was to give me a good gun for hitting the type of target I'm after...but if I want to aim it at my foot, well, c'est la vie.

Re:To OOP or not to OOP

[sporty]

Right, but being able to shoot yourself in the foot in arcane ways. I.e. c's gets() function. There are alternatives that aren't buggy when used wrong.

It's kinda why I like java so much. It assumes to some degree that programmers are either careless, make mistakes, or just plain stupid :)

Re:To OOP or not to OOP

[Lordrashmi]

I am currently just learning java so I could be way off base on this, but I see several ways to do things, including some old, should be deprecated ways.

I don't believe the language should force an engineer to behave though, I believe engineers should be able to choose the best path.

Re:To OOP or not to OOP

[sporty]

Granted. Just like we all take different roads to get to different places. By allowing people to do bad things is just as bad as promoting. Writing bad algorithms is a better limit to buggy code than writing code that causes overflows or structual limitations on the architecture.

Books don't suck

[Infonaut]

Some people, self included, simply grok things better when they have a book on the desk. Personally, I hate shifting back and forth between the code I'm trying to write, and online documentation. I don't have acres of screen real estate, and I find that it's easier to read a book for long stretches of text anyway.

I can read a book while I'm sitting on the back balcony, in a relaxed position away from any keyboards (yes, some Slashdot readers do step away from the computing devices from time to time). I can very easily annotate the book with this thing called a highlighter. I can even make notes in it with a special "pen" device.

Don't give me the expense argument either. Forty or fifty bucks for a good computer book is like an investment in your future employability. For most of us, this book will cost less than we'll bill for an hour or two of work.

If you don't like computer reference books, that's fine, but realize that for some of us, they're quite handy and worth the money.

Re:Books don't suck

[Jobe_br]

Very nicely put. I'd like to chime in and say that reading programming books out on the deck is sweet. Yes, I could drag my 802.11b hooked-up Latitude or iBook out there, but its a lot easier to read a book when its *sunny* outside than it is to see an LCD screen! :)

Having a good library of computer books is about the best investment in ones future that any programmer can make. I've known of folks that grab a C programming manual that's easily 10 or more years old, just for the odd algorithm that showed up in there that they'd like to use for something. I've grabbed my old Ada83 books for info on setting up certain data structures easily.

To each their own!

Cheers.

Re:Books don't suck

[mgkimsal2]

Not sure if you're replying directly to me or not - I didn't say 'books suck'. Many of the PHP books out there do suck somewhat, because they are mostly reprints of the manual, and reprinting of mostly less-than-useful functions (mSQL, Interbase, etc.). The huge majority are using PHP and MySQL, and even more to the point, often times these books only have examples relating to MySQL anyway, so including 3 pages of info on interbase (manual reprinting) is just filler, making it look like there's more useful info in there than there is.

I like books - I buy them myself. I just think most of the PHP books out there now are repeating the same stuff. You can get by buying one of them, and essentially have covered 6-7 of them. It's pretty much the same as ASP books or Java books or other languages - there are so many publishers looking to get something out that there a lot of filler and a lot of repetition nowadays - a stark contrast from 1998. :)

Re:Remote Object Calls.

[kzanol]

PHP still doesn't have Remote Object calls correct? What sort of Remote object calls do you need?

• 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 started :-)

Time frame

[Pac]

I think you are under the impression the "dotcom" style of software life-cycle (develop today, throw away tomorrow) is the market standard.

Well, it is not. In the real software development world, you don't plan for the next year, you plan at least for the next five years (more, if you are really smart). Or have you not noticed the Y2K panic was mostly caused by 20-30 year old software still being used in production environments?

There many compeling reasons to take cross-platform capabilities into account. There are measured data showing somewhere up the scale it is cheaper to buy a very expensive Sun or IBM machine than keep throwing Intel hardware at a problem. There is also the corporate climate changes and technological advances to take into account. And I am not talking just about Microsoft licensing problems, but also about the forseeable Linux future.

All in all, dismissing the possibility of platform exchange is a risk most large projects prefer not to take, specially because it is more and more an easily avoidable risk.

Re:Time frame

[NineNine]

Well, with web apps, scalability *shouldn't* be a problem. The problem with most web apps is that they're written and architected wrong. Most that I've seen lean very heavily on the web server, thus that's the bottleneck, which is why you see server farms.

In reality, the bulk of any web app should be in the database. The majority of people building web apps know little to nothing about databases except for SELECT * FROM TABLENAME, so all of the heavy lifting is done at the web server. If databases are left to do what they're designed to do, and that's retrieving, AND manipulating data, then the web server becomes increasingly less important. If the app is designed correctly, different web servers should be able to hit the same databases with minimal coding done at the web server. Unfortunately, again, most people don't do this out of sheer ignorance. Thus, cross-platform shouldn't be a concern with web servers. Don't like like IIS for some reason, switch to Tomcat or Apache.

And this problem is also why you see so many people (at least in small projects) using a very feature and performance poor MySQL. A robust database, such as Oracle, SQL Server, or DB2 can do the work for you, with half of the hardware needed, and twice the performance. Heck, Oracle even has a web server and their own scripting language.

My experience is *not* with dot-com anything. My experience is with large, mission-critial web applications. Most large organizations have standardized on a platform, and don't just "switch". A major platform switch is a time consuming, expensive task that is only done when absolutely necessary. Thus, an application written that has an expected life, of say, 5 years, is very unlikely to be forced to move platforms within that time. Again, I'm talking about mature companies, not stuff started in people's basements.

Re:Bah!

[Pinball Wizard]

That's hilarious. I only wish he had a turtle so I could create a more definitive "Programming Logo" cover.

Re:Remote Object Calls.

[$rtbl_this]

Me too. :)

I work for a Fortune 50 (no, there isn't a 0 missing off that) company and we use PHP quite a bit internally. I also do some freelance web work in my spare time with a friend who is a designer with no coding experience, and even he can get the basics of an interactive site together using PHP (provided I go in afterwards and secure things afterwards - sorry, Joss!) :)

PHP is fast, easy to use, feature-rich and well documented. Development of most simple interactive pages almost feels like cheating because there's generally a built-in function for anything you need to do. Now with the availability of database abstraction and templating most of my old complaints about it have been addressed and I find myself working with it more than Perl.

good but not great

[mlong]

Being the first edition, it does have some quirks to iron out which I have forwarded to the author. For example, it may talk about one alias to a function but not another, which would be helpful for Perl programmers and the like (for example, split is an alias to explode and join is an alias for implode). There were also a few issues with some of the functions in the book where they mixed up the argument order. Also I felt they didn't put near enough time into optimization, whereas the Perl book spends quite a few pages discussing it (I think the PHP one maybe had one page on it). There were some small things they skipped over which could make a difference in huge projects (when to use "" and when to use '') and whether to do print "$a$b$c" or print $a,$b,$c or print $a.$b.$c, etc. But overall this *is* the best PHP book I have read and I do look forward to their next edition.

Re:good but not great

[Rasmus]

Except split() is not an alias for explode(). One takes a regex, the other doesn't.

Re:good but not great

[mlong]

Except split() is not an alias for explode(). One takes a regex, the other doesn't.

Ah I learn something new everyday. Coming from a Perl background I almost always use split by default, which works on expressions.

Re:good but not great

[h3]

(for example, split is an alias to explode and join is an alias for implode)

Actually, watch out for this - split is not an alias for explode. split uses regular expressions, explode uses strings.

-h3

Re:Remote Object Calls.

[Jobe_br]

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.

Re:Remote Object Calls.

[killmenow]

Its pointless for all but smaller sites, businesses can't use it without remote calls.

I am trying not to be offended by your arrogance. I take it you think smaller sites are all just hobbyists or bloggers?

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:

• there are approximately 25 million small businesses in the U.S.
• new business formation reached another record level in 1998
• there were 898,000 new employer businesses in 1998 -- the highest ever and a 1.5 percent increase over the record of 889,000 new businesses in 1997
• In 1998, seven of the 10 industries which added the most new jobs were in sectors dominated by small businesses (U.S. Department of Labor, U.S. Department of Commerce)
• small businesses hire a larger proportion of employees who are younger workers, older workers, women or workers who prefer to work part-time
• small businesses provide 67 percent of workers with their first jobs and initial on the job training in basic skills
• small business bankruptcies are the lowest in 19 years

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.

PHP installed != PHP being used

[dananderson]

NetCraft reports are a poor measure, not because NetCraft is inaccurate, but many have out-of-the box installations (say from RedHat) that have PHP installed, use it or not. Many or most do not use PHP.

That said, I do have a gut feeling PHP is overcoming or overcame ASP.

problem with web lang books

[Tablizer]

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.

Re:problem with web lang books

[toby]

While what you say makes perfect sense, I'm guessing that publishers do otherwise because, when told "Go learn PHP!", the average dude is more likely to buy a single book that appears to cover everything, than two complementary books. Especially when the common aversion to reading is taken into account.

ASP? why why why?

[no soup for you]

Could be slightly offtopic, but I want to make two points:
1) ASP is not IIS's version of PHP
2) ASP is not what most IIS development is in

opinion - ASP has the lowest learning curve of any web programming language
opinion - Most websites will not use ASP, even if they are using IIS on win2K. The site will create a COM object and give it control. ASP is a horrid environment for internet sites: it's interpreted and all variables are variants - even integers.
scary fact - There are no permissions to set in ASP. each page can execute anything that the server can. And if you're generating your SQL statements (rather than stored procs) based on user input it can easily be stolen and replaced with a drop all command.

So don't consider using asp, seriously - you get no gains whatsoever.

Re:ASP? why why why?

[Lordrashmi]

I found ASP more difficult to learn the PHP, though I have to say since I learned PHP first and ASP second, I could be biased.

I also disagree that most websites will not use ASP for a webpage. Too many sites I see use ASP for everything and they pay a heavy price.

Re:Remote Object Calls.

[SirSlud]

We are a business. We serve Fortune 500 clients. We don't need no stinkin RCs, and thank the fucking lord we dont have to write the front-end of our app in JSP, Perl or C ... yay for PHP. Talk about a time/money saver.

Your attitude is that of the 'cookie-cutter' CS grad. What you might learn in the future is that you shouldn't throw out the entire code base with the missing feature.

Re:how relevant is PHP today?

[Twister002]

I've programmed in both ASP and PHP, started out using ASP. I've been doing more and more PHP programming by choice recently due to the performance benefit I've seen by using PHP.

I converted my personal ASP site over to PHP some time ago and noticed that it ran MUCH faster using PHP, page loads were faster, DB queries we faster, etc...

Comparing them side-by-side on a Windows machine, I've still seen better performance out of PHP than ASP, even ASP server side components. Plus the ability to call both Java and COM objects on the same page makes it a no-brainer for web development. (especially how long it took VBScript to get regular expressions)

Now ASP.NET and JSP, that's a different story... but PHP kicks ASPs butt every time.

Re:how relevant is PHP today? [OT]

[caldroun]

I am in the NC / SC area. Now in all fairness, I do talk some people into using PHP, but it isn't hard. I mean the benefits of not having to be Platform dependant is appealing to most (Cost is a big factor too).

I talked the Law firm that I work with into using PHP for our Intranet about 2 years ago (when we were doing a re-write) and we dumped ColdFusion. (I dont like having to pay for upgrades on the servers, although I know that the firm I am with could easily afford it)
Now, I have an Extranet, and Intranet, and our external site with PHP/ Mysql.

There is Web Devel work in my area, and a lot are receptive to PHP. No doubt.
It just makes better sense.

Re:What about Perl?

[CableModemSniper]

So write one.

Re:Remote Object Calls.

[waynetv]

What makes it worse is they are trying to make it more OO by re-inventing the wheel.

How so? There OO layer was pretty much stapled onto their existing design but I don't consider that reinventing the wheel.

If they used an OO language underneath, they can make it more OO like.

PHP5 (which has been released in beta form and has been in development for a long time) will have a much more sane OO model that will be familiar to anyone who has used Java or C++.

PHP always acted like a complete hack of a language vs something that was engineered.

Definately. The low-level foundation of PHP has been constantly improving. I suspect there is alot of engineering in there. But PHP provides only a thin layer on top of other open-source technologies..

Look at the database layer? No common functionality.

Yeah, that's cause it's not a database layer. The database API is the one exposed by the database client library. Every API is different because every database vendor does something different. This is not the fault of PHP. Most languages FORCE you to go through some kind of abstraction (Microsoft has ADO and ODBC) which just does exactly what PEAR::DB does. But if you only use one DB type, or need some special functionality of the API, then for best performance and compatibility you'll want to use those base APIs.

Pear is cool and all, but by making the old calls avail, you allow users to still shoot themselves in the foot.

I for one don't use PEAR::DB. I have my own database abstraction for my own projects which, of course, makes direct calls to the database. So I'm happy for the ability. (Same goes for the other API's as well) You can't shoot yourself in the foot using the database-specific API's.

Re:Quality questionable

[loginx]

So basically you're saying:
I'm talking about a book that I have not read.
However, I read another book that sucked.
so it must suck.

Sorry, doesn't make any sense to me...

Re:Remote Object Calls.

[sporty]

Yeah, that's cause it's not a database layer. The database API is the one exposed by the database client library. Every API is different because every database vendor does something different. This is not the fault of PHP. Most languages FORCE you to go through some kind of abstraction (Microsoft has ADO and ODBC) which just does exactly what PEAR::DB does. But if you only use one DB type, or need some special functionality of the API, then for best performance and compatibility you'll want to use those base APIs.

I for one don't use PEAR::DB. I have my own database abstraction for my own projects which, of course, makes direct calls to the database. So I'm happy for the ability. (Same goes for the other API's as well) You can't shoot yourself in the foot using the database-specific API's.

Ok, layer is a word i use only because it should be seperated somehow.. perhaps i'll just use the word api. Fine, every DB vendor does things differently, but there is a LOT in common. How do you think perl's DBI layer works? They use dbd (iirc) for the specifics and interface it into dbi, a common ground.

The disadvantage of using the specific api's? Try switching databases and watch the chaos ensue :)

Re:Remote Object Calls.

[waynetv]

Ok, layer is a word i use only because it should be seperated somehow.. perhaps i'll just use the word api. Fine, every DB vendor does things differently, but there is a LOT in common.

Perhaps. But PHP just exposes the DB vendors API. That's all. PEAR::DB and ADODB are the abstraction layers. It's just that in most languages that layer is hidden from you. In PHP it's available. It also means that the abstraction layers are written in PHP (which is a good thing)

So there are two reasons the DB vendors API's are exposed in PHP:
1) You can write your own DB abstraction layer.
2) You can go the "bare metal" if you need performance and not database portability.

I really don't see what is so bad about that.

The disadvantage of using the specific api's? Try switching databases and watch the chaos ensue :)

Of course! Why do you think PEAR::DB and ADOBD (and Metabase) exist. You can always just use the ODBC functions, too.

Re:Remote Object Calls.

[sporty]

The performance increase between using exposed and hidden functions is minimal. If you should want to write your own abstraction layer, it could be done on top of a common one. Say I don't like perl's DBI and i like procedural programming. I can write a layer on top of it. If I also want to, i can replace DBI using what DBD provides. And perl's method of db communication isnt' hidden by far. Just like php's module interface isnt' hidden, though VERY poorly documented.

PEAR::DB and ADO:BD are carpets which the dust has been swept under. By leaving them exposed, they allow people to make things more difficult. It's like putting a cardbord box over a gun in your house. Sure, the problem doesn't look like it's there, but you can easily find the gun and shoot someone.

What I'm saying, is that the mix-matched-names are bad. VERY bad. They show no relationship to a higher level of commoonality. There's no common prepare_statement(databse_handle,statement) type structure. Everyone does what they want. And if you have to switch db types, you have to relearn everything.

Re:Remote Object Calls.

[loginx]

Abstraction or Performance is a trade-off
Do we want to allow the professional to create a robust and fast application adapted to a specific database without giving too much overhead ?
Yes we do!
Even though we risk other users who do not read the manual to shoot themselves in the foot ?
I'm sorry but yes we do!

I actually use PHP to do entreprise programming actually and the applications scale perfectly to multiple servers, large databases and frameworks.
The Java AND python integration is perfect and creating C extensions give you an edge.
That is, if all your knowledge is not based on other "scripting" languages... but that's not the case since you're an entreprise developer, right ?

Another good book

[PhilipChapman]

A book that I found EXTREMELY useful was "PHP and MySQL Web Development" by Luke Welling and Laura Thomson. I had virtually no programming experience, but picked php up VERY quickly with this book. Its nice because it uses real world examples and shows you how to use php to interact with MySQL. This book looks great too, I'm gonna go pick it up.

Can PHP do this...

[rosewood]

I have really limited web experience but I have a simple need.

Basically, pdf files are generated in a directory. I need a user to be able to see all pdfs in that directory, be able to 'delete' the one he needs after he downloads it, and have the file really be deleted after 48 hours of being marked as for delete

I have *no* idea how to do this, but what little ive looked at says I need php

Would php be able to cover all of this, and if yes, would this book tell me how to do this?

Or should I learn another programing language first?

Re:Can PHP do this...

[jwinter1]

Okay, here's what you want:

Directory listing.

Deletion 48 hours after a Delete link is clicked.

You can do a simple directory listing in PHP quickly and easily(just copy apache's look and feel for directory listings and add a Delete link after each entry). That delete link will be harder. Make the GET string for each delete link unique to the file that will need to be deleted, e.g. delete.php?file=My%20Word%20Doc.doc, etc., and have delete.php write the file name to a text file you'll read with a cron job.

Now you'll need a cron job to run every hour or half-hour (does the file need to be deleted exactly 48 hours afterward, because that would be harder) and have a perl or shell script read the file names and delete them.

Hope this helps.

Re:Can PHP do this...

[tmark]

Yes, PHP can do this. As others have pointed out, the actual deletions can't be done by PHP by itself and you need to schedule (say) cron-jobs to run the deletion. What the other posters neglect to mention is that you can schedule cron-jobs to run PHP from the command line and do the periodic deletions.

However, using PHP to do the latter would probably be unnecessary and you could do the same with a shell script. But technically, yes PHP can do everything you want.

Re:Can PHP do this...

[ubiquitin]

Use exec() for deleting the files after they have been accessed. Deleting 24 hours later will require some timed event (think cron.) Here you go:

<?php
$dh=opendir('/home/');
while($ file=readdir($dh))
{
print"<ahref=$file>". "$file"."</a><br>"."\r";
}
closedir($dh);
?>

Re:Remote Object Calls.

[SirSlud]

Hehe, and here I thought I was being rude. I'm going to have to work on that. ;)

Seriously tho, I understand that peoples views stem mostly from their experience, but thats pretty much the golden rule of software: Even enterprise businesses have suitable uses for non-enterprise software. There is always a time and place for high load distributed multi-tier web applications, and PHP can be a little out of its element in really large deployment environments if developers treat PHP like its a stand-in for other enterprise web app platforms ... but any good solution suite should be componant based .. sometimes the cost of supporting another platform is outwieghed by the cost of solving a small problem with enterprise technology (ie, solution overkill).

The Right Tool for the Right Job; just dont assume the kinds of jobs you have to do have any intrinsic relationship with the size or worth of the company. Case in point: A small internet advertising delivery company will have a much greater need for performance and speed than a large company with thousands of clients on a web application. In this example, its the small company that needs the robust, extensible framework, while the larger company can probably get away with building their front end in PHP. And of course, many companies will need both (high performance servers with lightweight web front-end) so using both enterprise-style platforms and lightweight style platforms (PHP and Perl) is not uncommon in the same organization.

Anyhow, toodles!

Re:Remote Object Calls.

[SirSlud]

> Pear is cool and all, but by making the old calls avail, you allow users to still shoot themselves in the foot.

Uh yeah, mostly because, as programmers, its our job to hold the gun. Not knowing which body parts to shoot, ours or otherwise is the sign of a bad programmer, not a bad API.

I like having the options. On portable projects, I can use one of the many abstracted db layers. On non portable, I can just rip through development with the mysql-specific apis.

If they didn't make the naked db-specific APIs available, nobody else could developer their own home-cooked abstraction layer. If you dont like Pear:DB, at least there are alternatives.

php

[richchri]

since when do good programmers use php? is this new book a pop-up book with colorful pictures?

Re:php

[dfj225]

I would say that good programmers have been using PHP since the first person used PHP to complete a project. In other words, since the creation of the language. I use PHP, and as a web development platform and it is great for that purpose. Just about anything you could use Perl to do on the web, PHP does, and many tests show faster.

Re:Remote Object Calls.

[sporty]

Yes, but abstracting is such a minimal performance loss that there's no reason why it houldn't happen. In fact, if the DB was made common, we wouldn't need an abstraction layer on top of it. Since everything

The problem with php, is if the application's require/include tree get's large, it has compilation problems at times. Granted, you may not see it easily, but I've seen it happen on files that just declare variables.

And my knowledge is based on C, C++, perl, java and php, so no need to get sarcastic ;P

Re:Remote Object Calls.

[sporty]

Yes, but by not preventing people from making bad decisions is just as bad as promoting it. It's a bad mark on the language to allow bad things to occur. Look at c. buffer-over-flow city. If you knwo what you are doing, of course you'll win out, but you brin in a developer who doesn't think of the long term effects of gets() or the long term effects of using functions that are only usable with one db (switching db's becomes a pain), you lose.

Re:Remote Object Calls.

[SirSlud]

First off, we're not talking about PHP the language; the complaint was specifically against the API provided with the language.

That said, I really hope you're not comparing language weaknesses like making buffer over flow errors easy to commit and 'weaknesses' like letting the developer choose speed-vs-portability.

Good programmers still make little mistakes like off-by-one and buffer-overflow errors, and sure, you can say the language is asking for it in the case of C. But portability, when the api function names specifically refer to the database you are programming non-portably against is something the developer should be intrinsically aware about .. this is not a problem subject to little one line programming slips .. youd have to be a pretty lousy programmer to use mysql_dothis, mysql_dothat and then get pissed off after 5 weeks of development that your code isn't portable to prosgres or whatnot.

You're almost saying that all hooks of an API should be horizontal, and never heirarchiel; and that it is the weakness of an API when the programmer uses non-portal code that is clearly named and documented as such (?!). Its a completely unreasonable and very inefficient approach; at the end of the day, the developer needs to have some accountability and responsibility for his use of the tools presented with him. Seeing as the PHP API makes it very obvious (as in right in the function names) which level of portibility you are programming to, I wouldn't hesitate for a moment to fire a programmer who accidentally wrote a PHP application using the mysql-specific calls when the requirements of the project included database portability. Wouldn't you?!

Re:Remote Object Calls.

[loginx]

I have to say I disagree with your first argument. Database abstraction is a very convenient thing, especially to port applications. However, using a workaround query to replace an embeded algorithm will in certain cases cause you severe performance problems. Just run the benchmarks for yourself with PEAR, you will add great flexibility but if you really want to focus your application on performance, you will find a more addapted algorithm and reduce the amount of overhead. Agreed in some cases the difference might not be worth using the old way but there is still a need for it in some applications. That was my point. Also I would add that many developers didn't even switch to the new $_* arrays, I don't think they will ever switch to a different database access method. And I didn't notice compilation problems with PHP's include and require tree but my include/require tree has never exceeded the 10/11 files. And as for calling this "the problem with PHP", I simply never heard that argument before and if the problem can be identified and exposed, most certainly it will be fixed rapidly. And I'll skip the sarcasm since you're familiar with the subject you're talking about :)

Re:Remote Object Calls.

[sporty]

I wouldn't hesitate for a moment to fire a programmer who accidentally wrote a PHP application using the mysql-specific calls when the requirements of the project included database portability. Wouldn't you?!

I would. Because it depends on the position of the programmer. Is he a junior programmer? If so, I wouldn't want to fire him since he may not have the knowledge to do any better. That's why a good language or api would support the programmer and not be a wasteland (severity not intended) of things you can do.

And just 'cause things are obvious to you, maynot be obvious to you. :)

Re:Remote Object Calls.

[sporty]

And I'll skip the sarcasm since you're familiar with the subject you're talking about :)

Thank you my liege! ;) heh

Agreed in some cases the difference might not be worth using the old way but there is still a need for it in some applications.

My argument is in MOST ways you'll not see much speed differece, and the bit you see in load you can throw one more server in the load balancer pool AND... (and...) what you lose in speed, you'll win back in development flexibility, wether it's changing DB's or developing new code. I'm sorry, having oci and oracle libs at the same time, and not deprecating one really.. bugs me.

You mean the Universe PHP Extension

[MelloDawg]

Universe is the successor to Satellite. It is a binding to the MICO CORBA ORB. See http://universe.2good.nu for details.

No, that's Perl.

[wackybrit]

Oh hang on.. I forgot.. PHP is just a Perl ripoff that has even less features.

Continue with your code.

Re:There is no programming in PHP

[SirSlud]

If you can't figure out how to sperate your data-access, display, and logic layers in PHP, you are as much a "programmer" as you credit PHP with being a "lanuage". Meaning, not much of one at all.

There are tons of huge sites out there that use php. You can apply standard software engineering design and analysis skills to PHP, including but not limited to UI/Logic separation, profiling, OO, etc.

Web applications are and will never be the ASMs you cookie-cutter CS grads want it to be, so get over yourself and accept that procedural scripting languages can be suitable approaches for even large websites.

And Lisp? Even lisp.org seems to indicate that Lisp can be interpretive in the same manner PHP is, and states that the interpretive nature of Lisp is actually a strength, not a weakness as you contend it is with PHP. I guess you'll have to de-learn Lisp and stop "hacking" in it, huh?

Get your head out of your bum.

Re:Remote Object Calls.

[JebusIsLord]

I don't think by using the mysql-specific functions I am shooting myself in the foot. in fact, they are significantly faster and since i have no intention of switching DBs or porting to other machines, that is clearly the way to go.

Yet another PHP book

[MartinLuther]

As a professional PHP developer, I've found Web Application Development with PHP 4.0 to be one of the best books I've ever purchased. The authors, Tobias Ratschiller and Till Gerken, don't spens time and paper reprinting the manual. instead, they discuss the abstract concepts that distinguish a well-written webapp from a poorly-written one.

Coding conventions, organizing libraries, API design, and programming in a team environment are all discussed in depth. They include case studies and real-life examples of the concepts they cover.

To summarize, if you want a great discussion of PHP development that you *can't* get from the online manual, check this one out.

example of distributed computing with PHP

[drugdealer]

If you'd like to see a real-life example of distributed computing with PHP, take a look at the LiquidClassifieds/LiquidClassifiedsXML web service.

Re:Remote Object Calls.

[killmenow]

"...as long as I'm rich", and I'm the arrogant one.

I'm glad you noticed my signature. It has nothing to do with the posts. If you miss its point, well, sorry.

I'm trying to take a higher road than you here,

Aside from calling you arrogant (you may well not be...but your post sure was), I don't know what road I'm on that's any different from you. Perhaps I misspoke when I said "your arrogance" as I should have better said "the arrogance this statement implies." Of course, you said you'd try to take a higher road, after just implying I was arrogant, not you...and you did it again at the end of your post. I guess you failed at taking that higher road. It appears to me we're both calling each other arrogant. I am. I admit it. It's a character flaw. Sometimes it gets me into trouble, but I don't deny it's there. I'm working on getting over myself...but I'm just so good, you know. I quote Mac Davis

Oh Lord, it's hard to be humble
When you're perfect in every way

I know, I know. It's not very nice of me to flaunt my greatness in front of those less fortunate...but then, you need someone to look up to after all...I guess I can help you there.

1. I meant no attack on anyone, if you took anything in my post personally you have issues of your own to work out.

Oh, I took nothing personally; but, thanks for pointing out those issues I must have. You probably get a better view of them up on that high road. I merely thought your statement showed an attitude that was either: a) uninformed, b) elitist, or c) both. So I thought someone should say something to you.

2. I just replied to another saying that pehaps my "pointless" statement was too harsh.

Yes, perhaps it was. In its bluntness, it came across ... well, as I said above ... c) both.

What I tried to imply, and in my idoicy compared to your higher intelligence, came out sounding like a blathering idiot

Well, at least you're willing to admit it.

was simply suggesting that without the use of Remote Calls an n-tiered network would be extremely hard to achieve.

And there you are probably correct. And had it been put so initially, I doubt anyone would have argued with you at all. But simply saying it was completely useless for business is incorrect and so you ruffled some feathers.

But thanks for all your stats,

Well, they're not exactly mine...but you're welcome anyway.

I totally read them all,

In that Bill Cosby doing Noah voice: Riiiiiiight.

and I'm glad I'm the arogant one.

Me too.

Re:Remote Object Calls.

[waynetv]

The performance increase between using exposed and hidden functions is minimal.

MySQL, for example, exposes a number of different functions with different performance characteristics. By using the functions directly, rather than going through an abstraction, I can guaruntee that I don't make extra unnecessary calls to the database. As it stands, my abstraction layer makes all those calls and I probably lose a bit of performance by doing that.

If you should want to write your own abstraction layer, it could be done on top of a common one.

A common DB abstraction layer is more complicated than you seem to think it is. I kinda like the fact that PHP developers work on PHP and everyone else works on the DB abstraction layer.

What I'm saying, is that the mix-matched-names are bad. VERY bad. They show no relationship to a higher level of commoonality. There's no common prepare_statement(databse_handle,statement) type structure.

MySQL has no concept of prepare_statement, what would you do in that case? The names of the functions are the actual names exposed by the underlying C client libraries. The Perl abstraction layer has to call these exact functions with their wierd names. Sure, it hides that from you. But that's just what PEAR::DB does.

Re:Remote Object Calls.

[sporty]

Unless you know the future of everything you'll ever do, you will never know if something wont' come along.

You start with a specific idea but make things general enough that if you change certain variables it won't be the death of everything. DB's, db strucutre, template engines are major points for speed improvements. So if one DB is faster than another or another template engine is better, the work becomes less.

Re:Remote Object Calls.

[sporty]

MySQL has no concept of prepare_statement, what would you do in that case? The names of the functions are the actual names exposed by the underlying C client libraries. The Perl abstraction layer has to call these exact functions with their wierd names. Sure, it hides that from you. But that's just what PEAR::DB does.

Right. PEAR::DB does a great job. Now hide the extra functions! :)

As for your mysql thing, you make prepare remmeber the statement you want to run, like a good abstraction layer normally does (that we've seen so far, like pear::db or perl's dbi).

Much more useful

[kellan1]

People always talk about how wonderful PHP's online documentation is. Its okay, and the section at the end with the gazillion functions is certainly comprehensive (and reminds me why PHP is not my first choice of programming environments).

However, I thought this book was *much* more intelligently organized. The section titles made sense. A was followed by B was followed by C. It spoke about good practice and design.

If this is what most people learned to program PHP with there whould be significantly less horrid PHP in the world. I think this is actually a return to the Oreilly golden era, away from poorly concieved fluff books like Essential Blogging.

Now if they could come up with a PHP (or Python, or Java) cookbook as good as the Perl cookbook, we would know that the good days were here again.

Re:Quality questionable

[genkael]

Same author same publisher same topic.

Re:Remote Object Calls.

[Rasmus]

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.

Re:how relevant is PHP today?

[loconet]

PHP is used for more than your "small" MySQL-based website. Not only does it support a lot other databases beside MySQL,
but it scales very good too.

As for ASP, a good programming enviroment?
*laff*

You need to lay off the crack buddy...

[cscx]

Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.

http://sourceforge.net/projects/scoop

Scoop is a weblog script written in Perl with a MySQL backend. It is different then other weblogs, in that it allows the users to decide what stories get posted.

Re:You need to lay off the crack buddy...

[loconet]

Wow, and what are YOUUUUUU smoking? .. I want some of that too dude!

By the way, how about you try reading the article?

Re:Remote Object Calls.

[Just Some Guy]

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...

Frankly, you're wrong. I've made $LARGENUM over the last six months migrating a few websites from legacy Interbase servers to newer Postgresql systems. The process was far more complex than it needed to be, especially since the SQL itself was very simple on each of the sites (no transactions, no views, nothing complicated). Why?

• In Interbase, you can do stuff like:
  
  while ($foo = ibase_fetch_row($resultHandle)) { ... }
  
  but in Postgresql, you have to:
  
  $max = pg_num_rows($resultHandle);
  
  for ($i = 0; $i { $foo = pg_fetch_row($resultHandle, $i); ... }
  
  
• When converting between MySQL and Postgresql, the inconsistencies are even more annoying. Check out
  pg_query versus mysql_query. Note that while the functions are nearly identical, the order of the parameters is swapped. Who the $#!$@# thought that was a nifty idea?
  

In other words, it's pretty much impossible to swap out a project's backend once you've started.

No, I've relegated PHP to the "toy language" category. Can it be useful on occasion? Sure. Will I use it to whip up a comment submission form or similar lightweight interface? You bet. But there's no way, ever, that I'll even consider PHP for serious development work in the future.

PHP & mySQL Programming

[thejames]

Aside from the PHP Programming book, I have to vouch for the PHP & mySQL Programming book... it's not the exact title.... the book is sitting there on my shelf... I'm just too lazy to turn around and read the title.

Anyway... I learned a LOT about PHP and mySQL and practical applications that are working out very nicely for my business. I was a total beginner at it, but it's given me a good reference source for future programming endeavours. Check it out!

Re:PHP & mySQL Programming

[isbhod]

if you're talking about the book from SAMS "PHP and MySQL Web Development" i agree with you. It's a great book for beginners to PHP and MySQL. I was completely new to both and now i use PHP adn MySQL every chance i get. Although i now use www.mysql.com and www.php.net for reference, and the book sits quitely on my shelf doing a good job of collectiong dust.

Re:Remote Object Calls.

[Rasmus]

Like I said, if you have trivial SQL, use one of the umpteen db abstraction layers that are out there for PHP, or know beforehand that you might need to switch databases and think ahead a little bit.

The order of arguments and the way the functions are laid out for each database are that way because they reflect the underlying API. People who already know the underlying API for a specific database are in heaven when they hit the PHP API for the database as there is nothing new to learn. And even better, they can use the per-database API documentation directly and have it apply to PHP.

You keep arguing the exact same point. You want the native db function to be an abstraction layer whereas the core of PHP provides a direct API interface to each database and pushing abstraction layers up a level. As far as I am concerned that gives you the best of both worlds, but I guess you don't see it that way.

Re:Remote Object Calls.

[Just Some Guy]

Here's the prototype for PHP's mysql_query:

resource mysql_query ( string query [, resource link_identifier [, int result_mode]])

Here's the prototype for mysql_query from mysql.h:

int STDCALL mysql_query(MYSQL *mysql, const char *q);

Since the arguments to PHP's mysql_query are swapped when compared to the actual C headers, I'm curious: what "underlying API" does PHP agree with? It sure isn't MySQL's own C API.

Re:Remote Object Calls.

[Rasmus]

Well, in that particular case they are swapped because you can't put an optional argument before a required one. In most apps you only talk to one database at a time so always putting in the link identifier (which is the MYSQL *mysql part of the low-level API call) was a bit of a hassle, so it was made optional.

Still, the name of the function and the way it works mimics the lower-level API, but yes, here and there we toss in a few changes for convenience. You can call it maintaining the spirit of the low-level API if you will.

Re:Remote Object Calls.

[sporty]

Yes, you'll save time, but you it'll be a little longer than 10 minutes.

First off, i have to learn a whole new set of DB function names since all of them have different names. Some functionality doesn't exist between the two db api's.. such as mysql and a prepare like statement. What if I switched from oracle to mysql? Now i have to restructure my code heavily. A prepare should remember what the query is and return a statement handler.

Secondly, most queries will stay the same. Most queries would be simple selects, insert's and deletes which are SQL (92?) compliant in the first place.

This is exactly the reason why php is not as enterprise level as say java. Even C++ has it's advantages, but it's all in the OO.

Re:Remote Object Calls.

[Just Some Guy]

Well, in that particular case they are swapped because you can't put an optional argument before a required one. In most apps you only talk to one database at a time so always putting in the link identifier (which is the MYSQL *mysql part of the low-level API call) was a bit of a hassle, so it was made optional.

But that's exactly my point. Why wasn't that also done for pg_query under the same rationale? The current situation has two almost identical functions with swapped parameters with no apparent good reason.

Re:Depends on how you use it

[axxackall]

grab one of your "real" programming languages and write an object that generates dynamic PDF's.

It's exactly what I am doing using Java implementation of XML-FOP. Check Apache FOP. By the way it is free :)

The other free PDF libraries are available for Common Lisp, Python, C

Conclusion: I know what I am talking about. But I am not that "expert" as you may think about me. Here is an example of what real experts are saying:

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.

Will you argue with Dijkstra? I won't. Although he is talking about myself as well - I am poisoned with PHP experience as you do. I just aware of that fact and you don't.

Re:Remote Object Calls.

[Rasmus]

Well, here we have only 1 optional arg and we can actually leave the order as is. With mysql_query() there are 2 so having the optional first is difficult.

But again, these are minor little things to change compared to converting schemas, stored procedures, triggers, etc. when you are moving from one database to another. At most you have to spend 10 minutes going through the prototypes for the 5 db-specific functions you used in your app.

Re:Remote Object Calls.

[Azghoul]

I admit that I am the judgemental type, but I have not lost your civility, or attempt to redress your mis-phrased post.

I'm curious: What limits are there to PHP that can be handled with Perl? Do you have an example? Or JSP for that matter. I have been of a mind for quite a while that all three can handle essentially the same things.