Programming PHP 228
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 |
This book begins as most O'Reilly "Programming" books do: with a brief introductory chapter. In Programming PHP, this chapter is very short, so don't look to this book for a gentle introduction. On the other hand, this is the perfect book for you if you are just looking to learn a new scripting language. The following chapters go over syntax, data types, built-in functions, etc. These chapters are a little dry, but move quickly and effectively demonstrate the unique features of PHP (as compared to other scripting languages).
Of particular interest to programmers who are interested in expanding their horizons to developing dynamic web pages are the chapters on PHP web techniques, security, and application techniques. The web techniques chapter gives a quick overview of HTML and the GET and POST methods (and why you would want to use one or the other). It then covers a lot of useful tips and tricks that may be foreign to someone who has done little or no web development. Topics such as getting server information, form processing, sticky forms, file uploads, document expiration, and authentication are covered. It ends with an excellent discussion of maintaining state from page to page and visit to visit, covering cookies and PHP's (very cool) session support.
The security chapter covers standard things you want to keep in mind when creating dynamic HTML. No surprises here, but it is always good to be reminded. The application techniques chapter starts with a collection of best-practices, tips, and tricks to make your development process easier and better. It concludes with sections about error handling and performance tuning. As with the security chapter, there is nothing here a good programmer doesn't already know, but you can never hear it too many times.
I think this is a great book for programmers who want to start developing dynamic web sites with PHP. It gives a detailed overview of PHP, lots of valuable tips, and a good sense of PHP's strengths.
As someone who has written a lot of code, but only a little CGI, I really liked the chapters that discussed application development techniques specific to the web. Along those lines, not much time is spent on standard coding techniques, so if you want to use PHP but have never written any serious code, you may want to look elsewhere for an introduction. For the rest of you, just think, you may never have to use CGI.pm again.
The index seems adequate, although I must admit I did not use it much on the first read-through. The book is so well organized that, when reading it, you do not have to flip around much. Perhaps someone who has used this book as a reference can comment further on the quality of the index.
Contents are available on O'Reilly's page LinksSee Rasmus's page for links to where you can buy the book (maybe he gets a kickback for the link). Of course, you could always go to a local bookstore and purchase it.
You can purchase Programming PHP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
PHP Security Papers (Score:1, Interesting)
Contradiction in Review (Score:2, Funny)
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 (Score:5, Insightful)
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
No contradiction (Score:2)
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:Contradiction in Review (Score:1)
Re:Contradiction in Review (Score:1)
This book is destined to become a classic (Score:4, Funny)
No, that's Perl. (Score:2)
Continue with your code.
Re:This book is destined to become a classic (Score:2)
$arrChildNames[] = "PHP Programming ".$lastname;
How about that?
--
Evan (no references - I didn't use an &)
Useful, but not necessary (Score:5, Informative)
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 [php.net] 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 (Score:1)
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 (Score:1)
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 (Score:2)
Re:Useful, but not necessary (Score:2)
Re:Useful, but not necessary (Score:2)
Anybody else notice that IE has a slew of undocumented, functional tags? <image> for instance.
--
Evan (no reference)
Re:Useful, but not necessary (Score:2)
Much more useful (Score:2)
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.
PHP reference (Score:2, Interesting)
Re:PHP reference (Score:3, Insightful)
I saw this (Score:4, Informative)
Re:I saw this (Score:2)
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 (Score:5, Insightful)
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.
Alternate Resource (Score:1)
Buy the book (Score:2)
Tip (Score:4, Informative)
www.php.net/mysql_query [php.net]
www.php.net/strftime [php.net]
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 (Score:2)
--
Evan (no references)
I reviewed this months ago (Score:2)
Book vs. online manual (Score:5, Interesting)
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 (Score:2, Informative)
Goblin
Books don't suck (Score:2)
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 (Score:2)
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.
good but not great (Score:2)
Re:good but not great (Score:2)
Re:good but not great (Score:2)
Ah I learn something new everyday. Coming from a Perl background I almost always use split by default, which works on expressions.
problem with web lang books (Score:5, Insightful)
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.
Can PHP do this... (Score:2)
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... (Score:2)
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... (Score:2)
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... (Score:2)
<?php
$dh=opendir('/home/');
while($ file=readdir($dh))
{
print"<ahref=$file>". "$file"."</a><br>"."\r";
}
closedir($dh);
?>
Yet another PHP book (Score:2, Interesting)
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.
Re:how relevant is PHP today? (Score:2)
Re:how relevant is PHP today? (Score:1)
PHP installed != PHP being used (Score:2)
That said, I do have a gut feeling PHP is overcoming or overcame ASP.
Re:how relevant is PHP today? (Score:2, Interesting)
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)
Re:how relevant is PHP today? [OT] (Score:1)
Re:how relevant is PHP today? (Score:1)
Re:how relevant is PHP today? (Score:2)
ASP is for people who don't mind paying for a good programming environment.
ASP (Score:2)
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 (Score:2)
ASP runs on Windows, Solaris, and Linux. That's three.
Re:ASP (Score:2)
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 (Score:2)
Re:ASP (Score:2)
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.
Time frame (Score:2)
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 (Score:2)
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:how relevant is PHP today? (Score:2)
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? (Score:2)
but it scales [kuro5hin.org] very good too.
As for ASP, a good programming enviroment?
*laff*
You need to lay off the crack buddy... (Score:2)
http://sourceforge.net/projects/scoop [sourceforge.net]
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... (Score:2)
By the way, how about you try reading the article?
Re:lol (Score:2)
thanks for the link (Score:2)
Also this doesn't relate well to other non-apache based tech's like ASP or ColdFusion.
-Jon
Re:thanks for the link (Score:2)
Also, Netcraft's survey shows steady increase in usage [php.net].
Re:Remote Object Calls. (Score:2, Insightful)
Lacking x feature or n widget doesn't necessarily stop businesses from using something, it just keeps them from using it for everything.
CORBA? (Score:2)
Re:CORBA? (Score:3, Informative)
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? (Score:2)
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? (Score:2)
Re:CORBA? (Score:2)
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:CORBA? (Score:2)
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
The "X doesn't have Y" syndrome (Score:2)
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. (Score:2)
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.
To OOP or not to OOP (Score:2, Insightful)
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 (Score:2)
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 (Score:2)
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 (Score:2)
Re:Remote Object Calls. (Score:2)
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.
Re:Remote Object Calls. (Score:2)
Re:Remote Object Calls. (Score:2)
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
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. (Score:2)
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. (Score:2)
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. (Score:2)
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. (Score:5, Informative)
(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:Remote Object Calls. (Score:2)
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?
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);
pg_query [php.net] versus mysql_query [php.net]. 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.
Re:Remote Object Calls. (Score:2)
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. (Score:2)
Here's the prototype for mysql_query from mysql.h:
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. (Score:2)
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. (Score:2)
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:Remote Object Calls. (Score:2)
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. (Score:2)
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. (Score:2)
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).
Re:Remote Object Calls. (Score:2)
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
Re:Remote Object Calls. (Score:2)
Thank you my liege!
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.
Re:Remote Object Calls. (Score:2)
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. (Score:2)
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. (Score:3, Informative)
Re:Remote Object Calls. (Score:3, Insightful)
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. (Score:3, Insightful)
I think your view is unbelievably pretentious considering that according to this [sbs.gov.uk] 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 [sba.gov] in the USA:
Also, small businesses...
Re:Remote Object Calls. (Score:2)
Re:Remote Object Calls. (Score:2)
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
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:register_globals (Score:2)
Not good practice, but can certainly do it if needed.
Re:Is this neccesary? (Score:2)
The "this book isn't necessary" chatter appears everytime