Slashdot Mirror
PHP Cookbook
The approach that the authors use in PHP Cookbook is great. Like most computer books, the authors usually include a summary (in sentence forms) to illustrate what the readers will expect in each chapter. Skalar and Trachtenberg take this even further by including some preliminary (code) examples to explain the general ideas behind each chapters. The examples in the book are self-contained. In most cases, I've found examples to exactly fit my needs -- this makes it one of the better reference books.
Each chapter in the book is divided into multiple sections of Problem / Solution / Discussion with a FAQ style. In each case, a simple description of a problem is followed by a PHP script as the solution. But the meat is actually in the discussions: in-depth details are included here, where the authors also include references, extended ideas, and scripts to inform the readers how much more they can do about the issue.
For example, I was going to add a simple script to my website to parse RSS/RDF files from certain news websites (CNN, Slashdot, ...), and use it as my Mozilla homepage. (Who wouldn't?) This script seems to be simple, but I may make a mistake here and there. As reference, I opened up the book to the section "Parsing XML with SAX." Then I realized the authors already had the script to parse RSS/RDF files in the discussion. Bravo!
For myself, the most useful chapters I found are: Web Basics, Forms, Database Access, and XML. There are also good examples in topics such as security, internationalization, and file processing/management. However, this book does not cover the basics of PHP. If you are a good programmer, you should be able to get away with this using the PHP Manual. A good book to learn PHP is Programming PHP, also by O'Reilly.
Although this book covers a wide range of topics, it does not cover topics like generating PDFs. I would also like to see the authors add one (maybe two) case studies in later editions. That would give the reader a more concrete example of how to combine tricks presented by this book. Other than that, at the price of $39.95 (or $61.95 CAD), this book is a great buy!
Topics
- Strings
- Numbers
- Dates and Times
- Arrays
- Variables
- Functions
- Classes and Objects
- Web Basics - available online as example chapter
- Forms
- Database Access
- Web Automation
- XML
- Regular Expressions
- Encryption and Security
- Graphics
- Internationalization and Localization
- Internet Services
- Files
- Directories
- Client-Side PHP
- PEAR
You can purchase the PHP Cookbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Linux comes with a php2asp utility, so that you can write scripts in your favorite language, then have it automatically turned into ASP for running on the WinDOS boxes that your boss bought (PHBs just love their FUD ;-)
it does not cover topics like generating PDFs
Isn't PDF a closed format? Can you generate a PDF with PHP without also generating an Adobe lawsuit?
Never confuse volume with power.
One thing I would like to see more PHP books do is to cover the various Security problems that are prevalent in many PHP based web applications.
Don't get me wrong, I find PHP to be the best and friendliest solution for many things, but some of the Security problems could easily be avoided with some common sense security advice.
In all seriousness I enjoy PHP because it is pretty self explanatory, and it can use plain old html inside it too. It's just nice to use a scripting language for the web that was made for webpages originally, not a language that was created for ...
Ignore the "p2p is theft" trolls, they're just uninformed
You would think slashdot was written in PHP, considering the amount of coverage it gets in the book reviews.
I forget...are we at war with Eurasia or East Asia?
Not to be confused with "PHP Developer's Cookbook" (ISBN: 0672323257 - Publisher: Pearson Education) which is a very well regarded reference for PHP. Just wanted to avoid confusion and suggest the book at the same time. There seems to be a flood of PHP/MySQL books out there, or people are just getting around to reviewing them....not sure.
"A teacher overheard him say that he was using PHP, and as part of our Zero-Tolerance policy against drug use, he was immediately suspended. No questions asked," said Principal Clyde Thurlow. "We're not quite sure what PHP is, but we suspect it may be a derivative of PCP, or maybe a new designer drug like GHB."
Parents are frightened by the discovery of this new menace in their children's school, and are demanding the school do something. "We heard that he found out about PHP at school on the internet. There may even be a PHP web ring operating on school grounds," said irate parent Carol Blessing. "School is supposed to be teaching our kids how to read and write. Not about dangerous drugs like PHP."
In response to parental demands the school has reconfigured its internet WatchDog software to block access to all internet sites mentioning PHP. Officials say this should prevent any other students from falling prey like Brett Tyson did. They have also stepped up locker searches and brought in drug sniffing dogs.
Interviews with students suggested that PHP use is wide spread around the school, but is particularly concentrated in the geeky nerd population. When contacted by BBspot.com, Brett Tyson said, "I don't know what the hell is going on dude, but this suspension gives me more time for fraggin'. Yee haw!"
PHP is a hypertext preprocessor, which sounds very dangerous. It is believed that many users started by using Perl and moved on to the more powerful PHP. For more information on how to recognize if your child may be using PHP please visit http://www.php.net.
As a web developer, php has been a real life saver.
It would take a whole lot of perl code to achieve the same functionality that can be accomplished in 200 well-written php code. (Depending on what it did - it's based off my personal experiences).
In addition, the ability to mix and match html/php on a cross-platform programming language, as well as write scripts that also run on the command line is worth it's weight in gold (note to people who don't understand that saying, it's really valuable to me). Although perl and cgi scripts can be ran from the command line, they can't have (X)HTML mixed in quite as easily.
Contact Me (got tired of viruses emailing me).
I've been doing PHP web development on and off for a couple of years now and I've always found that it's greatest strength has been the availability of very god online resources.
PHP.net and many other excellent resources are only a browser click away and remain up to date for free. PHP is one of those areas where I'll save my money and buy a book I'll get genuine reference use from.
The actual document specification for PDF is open. Adobe just happened to not only create the format, but also make the most popular PDF reader and writer (the Acrobat series.) There are, however, free alternatives such as Ghostscript that generate great PDFs from a Postscript file (which you can generate from any program in Windows just by checking the "Print to File" box on a Postscript printer.)
If you're interested in generating PDFs from PHP, there are a myriad of options available by searching Google. Some web hosting companies also support generating PDFs from PHP, which makes generating PDFs a cinch.
HTH!
Simpli - Your source for San Jose dedicated servers and colocation!
I've got the Perl cookbook, and have used many of the source code samples found inside in my work. However, most of the development I do is PHP, and I'm extremely excited to hear that they've released a cookbook for PHP. I reccomend this and the Perl cookbook to any developer who wants advice or inspiration.
Matthew Walker
http://www.tweeterdiet.com/ - My Diet Tracking Tool
1) consistant database integration - Why not have a SetDBType() function, rather than hardcoding mysql_connect, mssql_connect, myodbc_connect, pgqsl_connect, etc?
.NET support?
2) Native XML support - It's just not there? Why re-invent the wheel each time? Give us a good XML tree-walking engine DAMMIT!
3) sane and consistant functions. Single quotes, double quotes, some functions work with both, some work with one or the other, embedded html in an echo screws up if you don't double quote it, etc.
4)
In short, PHP is a good language for small projects, but just doesn't cut it in an enterprise setting.
I use it for just about everything these days over perl. Spam filters, graphing, smtp server, ncurses frontends for apps, fractals, you name it. I also post a lot of what I do in it on my site: http://lucifer.intercosmos.net/
anime+manga together at last.. in real time.
I'm a PHP/MySQL junkie, and every time I see anything about PHP on
</rant>
Im dreaming ofa big bndwdth, That can resist the
I actually bought a copy of this book, as well as the other one referenced in this review. I found them quite useful in learning PHP - the examples can be easily tweaked to create useful little applications. I haven't done very much with web programming except for few CGI-scripts and PHP definitely looks much easier way to create useful applications.
The examples of integrating to MySQL were especially useful as I have been playing with Microsoft Access using MySQL as server, and now I can easily create web views from the database!
What I want to know is if there's any way to do any sort of Reflection in PHP. I'd buy this book if it had anything on that subject. JSP, ASP.net, and ASP all have Reflection or at least some features similar to it, but PHP seems to have nothing of the type... and there are some types of code that are next to impossible to write without Reflection - things like XML serialization/deserialization in particular are a pain without it.
using namespace slashdot;
troll::post();
JP
function usual_slashdot_activity () {
while ($phpzealots == "annoyed") {
utter($meaningless_nonsense);
}
}
That wasn't so hard, was it?
Contact Me (got tired of viruses emailing me).
This book has been out for nearly a year. Is this news?
Then use the Alternative PHP Cache, and get that speed up another 25-400% (depending on the size and complexity of your program. Eat that, java.
Contact Me (got tired of viruses emailing me).
okay okay.. you got me.. (and yea, that was my background image for a while... mmmm background image)
anime+manga together at last.. in real time.
Since the "language of browsers" is ECMAscript it makes sense to use that on the server, too, so one doesn't have to constantly shift back and forth between languages.
That doesn't even remotely make sense. Most browsers have javascript built-in, so that should decide what language to use server-side? Personally, keeping javascript for client-side and PHP or whatever for server-side is less confusing. That contextual switch is easier when the client-side / server-side code looks different.
Now I'm off to find a review of a Javascript book, so that I can insert random comments about what a shitty little language it is. That will be quite helpful for someone who wants a book about Javascript, I'm sure.
Mike van Lammeren
It will challenge your head, your brain, and your mind.
Because it's easy, fast, and 'real' enough for the vast majority of quick webpages.
just like PHP
if you want a big, complex, very scalable website; it might be better to go with java, for everything else (>90% of cases, i'm sure) it's easier to do it with PHP.
just the same; if you want a heavy duty database, with lots of concurrent updates, and/or triggers, stored procedures and so... well you can do it with Postgres or mortgage your house and use Oracle. for everything else, it's easier, quicker; and usually faster to use MySQL
-Kz-
Relevant, real-life useful examples are given and even a seasoned pro like me picked up a few gems like the example user authentication code that utilizes a hash instead of having to go back to the database on each page fetch.
My bookshelves are full of PHP books but most of them are inferior to the online documentation at php.net. They add nothing and are a true waste of trees. This one, however, does not fall into that category.
AZspot
Remember, PHP is to ASP as Zend is to VBScript.
LRC, the best-read libertarian site on the web
*Obligatory PHP flame from the Perl Guy *
Of course unlike Perl there are no easy/good ways to create one in PHP
*/Obligatory PHP flame from the Perl Guy*
There are no good ways to create one in any language. Current solutions are either:
(1) A thin shell over text and graphics primitives
or (2) dependent on an external rendering engine which creates another format like Postscript.
I'd like a high-level PDF creation library that would let me, say, directly create a table that is sized to fit the contents like HTML, but unlike HTML, will split the table across multiple pages, repeating header and footer information. Sounds straightforward, right? Not possible now. I've checked with Adobe engineers, and it's not even possible with their $20K PDF generation toolkit.
I can just hear the XSL-FO people saying, "but it IS possible with XSL-FO." And it's also possible, given all the sand and steel you could possibly need, to build a window. Point is, it's currently way too much trouble. I'm sure it'll get there eventually, but PDF creation is really an idea in its infancy right now.
bp
Amen!
I did a lot of Perl development before switching to PHP, and some of the things you mention that are missing from Perl are readily available as modules from CPAN. But that just adds another point in PHP's favour -- the default install comes with all the stuff you mentioned.
Before anyone gets their Perl backs up, let me point out why a good default install is important for web development: you don't always have control over the server, so you can't always get the Perl modules you want. (But if you want to re-write your code, sometimes, you'll get what you need! (Couldn't resist.))
Mike van Lammeren
It will challenge your head, your brain, and your mind.
So what are you saying is better than PHP? Running ASP with Javascript (or ECMAscript to be pedantic)?
If you can tell me that handling forms and working with databases can be done better with something other than PHP please do.
Also, please tell us what is a 'bigger' language, if PHP and *gasp* Perl are so little?
I wonder because I started in ASP with VBScript. I learned Perl and PHP and now I do PHP pretty much full time. If I want a script that is blantent CGI I use Perl. To me PHP and Perl completely blow away (not blow chunks) ASP with VBScript -- they are far better languages for web development. I can't say exactly why I think that, but one of the main things for me is the quality of the community surrounding the language. There's a lot more user support for PHP and Perl which to me is more helpful than the MSDN library will ever be. I also like a lot of punctuation -- but that's just a personal preference.
As far as switching back and forth between languages (JavaScript and PHP, for example), I never thought it was so silly. To me, doing things client-side is distinctly different from doing things server-side. It's no problem to have different languages for those two things. Especially when have to limit what you do on the client side because every browser is different. It seems to me like wasted effort to spend to much time on JavaScript stuff, because lo and behold browser X won't support what I'm trying to do. If I do it server side in PHP, I have an easier time writing portable code.
You certainly have a right to advocate your language of choice, and probably a right to bash others, but could you explain yourself a little better?
My Karma was at 49, then they switched to words. All that work for nothing!
I'm pretty sure this is a troll (I mean, .NET support?), but since it's had a large amount of "Insightful" mods, I figured I would point out at least one misconception.
The parent poster complains about "consistant (sp) database integration" as one of the main problems with PHP. This is usually a problem noted only by those who haven't used PHP in serious development. Sure, if you're writing a 20-line script that you know is only going to use MySQL, then who cares what database connection statements you're using. However, if you're writing anything that needs to be more serious and portable, check out one of PHP's database abstraction libraries: ADOdb or Pear DB. Both of these libraries will let you abstract out database functions so that they aren't tied to one specific database.
Personally, I prefer ADOdb. Not only is it faster than Pear DB, but there's also a C port to speed it up even more. ADOdb also has more capabilities, and its author hangs out in their forums and is extremely helpful with user questions.
You have to change your mindset a bit to code with ADOdb or Pear DB, but it's worth the bit of extra learning curve to gain portability. Since ADOdb can generate insert/update SQL and also generate HTML tables, I find that I'm faster coding with it than I ever was with mysql_query()... and I can switch to Postgres or Microsoft SQL Server at any time without really thinking about my database code.
I hope this helps those of you who are still stuck with mysql_query() or similar. <plug>Also, we're a web hosting company that supports PHP 4.3.x, ADOdb and Pear DB, and we will answer your PHP questions as part of your web hosting package.</plug>
Simpli - Your source for San Jose dedicated servers and colocation!
to see a book that deals with advanced application design in PHP. The problem with PHP is that most PHP developers are amateurs who don't know the first thing about app design. At best, apps are written with objects used randomly to accomplish some tasks and mostly include files for 2 dozen reused functions (or functions that aren't even reused, but still included in every page).
At worst, every database connection is hard-coded in a different place and there are no comments anywhere.
In either case, my God help anyone who wants to add functionality. These same people need a good book on relational database design, or be subjected to 4 years of universigy RDBMS design courses like I was. IMO, if you aren't willing to slit your wrists to get out of an RDBMS design class, you haven't taken enough of them.
The global economy is a great thing until you feel it locally.
PHP actually is not a language. PHP is an engine for embedded scripting languages in markup documents. Zend is the scripting language that most people generalize as "PHP", but any other scripting language could also be developed and used with the PHP engine.
You have that ass-backwards. PHP is the language, Zend, the engine. Any other scripting language could be developed and used with the Zend engine.
Mike van Lammeren
It will challenge your head, your brain, and your mind.
I wonder because I started in ASP with VBScript. I learned Perl and PHP and now I do PHP pretty much full time.
I followed pretty much the same path as you, and once I tried PHP there was no turning back, especially once I discoverd the Smarty Template Engine. Everyone doing PHP development should check it out.
Mike van Lammeren
It will challenge your head, your brain, and your mind.
Can I get an ECMA engine for it?
I think a large part of the problem is that PHP is illsuited for many of the larger web applications it is being used for. Traditional Application Server features such as tag libraries found in JSP, ColdFusion, etc. would be good for separating the 'coders' from the 'presentation designers' in large projects, but that's not pertinent to security.
What gets large PHP web applications like web based mail user agents, like Squirrelmail, and content management systems like PHPNuke is that they have to keep a lot of temporary resources between user actions in a single session. Resources such as open files, sockets, variables in memory, for instance.
PHP's simple engine, and its lack of language features to support these features forces PHP web application developers to build and destroy many of those resources in the life-cycle of the script instead of the life cycle of the application or the user session that is more appropriate.
The larger the application gets, the more difficult it gets to build using the simple 'web scripts' programming paradigm PHP and Perl pushes developers towards. This affects security and performance.
The end result is heavy dependence on databases for variable persistance and error-prone algorithm concoctions, a la PHPNuke et. al.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Ok, so I guess you don't get the chance to recompile the php module either if you really need some extra fonctionnality your webhost doesn't provide on their default PHP install.
Fun fact, if the Perl modules I need aren't available, I can always upload them to my webspace as @INC points to ./ for modules. Something I can't do for PHP if I need the extra fonctionnality.
Nice one, trolling on top of a troll.
"Not to mention all the idiots who use words like boxen."
Anonymous Coward on Monday August 04, @06:49PM
I gotta remember to read all the replies before adding mine...
I expected somebody to come in and say, "PHP's object support is not very good and OO and GOF patterns are the savior of code management and mega-reuse and getting dates, etc. etc." But I have not seen that. What's an OO critic to do? :-)
Table-ized A.I.
PHP 5 will have much much better XML support.
There is a lot of work on a complete new DOM extension, which should clean up the mess done in domxml as of PHP 4. It will follow the W3C DOM API as much as possible and is completely rewritten from scratch.
Furthermore Sterling Hughes is working on SimpleXml. An extension which should make it much easier to access XML Documents with the usual PHP functions.
The SAX Parser in PHP 5 will also be based on libxml2 and not anymore on the aging expat library.
XML Validation, XPath and XSLT support are also currently revised and should be improved a lot in PHP5.
You seem to have missed it before so I'll say it again: you do not need MS in order to use javascript (and even ASP) on the server. And even on my worse day I would not defend VBscript - nor is ASP vbscript, so it doesn't matter. Saying "ASP sucks" is absolutely NOT the same as saying "vbscript sucks" - and vice versa.
PHP has a lot of user developed modules, but it still lacks a lot of the things provided right OOTB with MS ASP (or chilisoft with java). Using java alone will also get you that same power and more, but php on a good day doesn't come close to either even WITH all those widgets.
And if you want docs there are easily as many "javascript toolbox" sites as there are PHP - probably more, in fact, since it IS supported by MS in ASP and most of that code can be used in apache just as well. Honestly, the only thing I can see going for PHP is it's free - and in this case the "free" solution well proves that old adage about getting what you pay for.
Ever hear of EJBs? Java can beat PHP any day of the week in regards to massive enterprise apps. PHP only really beats Java on its speed of development simplicity of deployment. Those are big enough reasons that PHP is a strong contender for medium-sized web sites and some large sites, but when you need Java's advanced functionality, there's no making PHP work.
Actually, PHP really needs an app server (ala Websphere) and some sort of Servlet or EJB-like server-side object. The app server could handle database connection pooling properly, caching, application-level opjects, etc. If PHP ever gets to that point, then it will compete with Java on the high-end. Hopefully an improved object model in PHP 5 will start the process.
The global economy is a great thing until you feel it locally.
I both agree and disagree...
I hate having every_goddamn_function() in the global namespace. I would much rather drag in what I need when I need it, a la perl. However, what drove me from mostly perl development to mostly PHP development is that you're pretty sure you'll have most everything you need built in with the latter. The simple fact of not necessasrily having perl's DBI module installed on a server you don't control (and have no access to gcc on) forced the decision to use PHP for most things over here.
Of course, PHP might not have everything you need built in, either. Need to generate images? If the server doesn't have PHP compiled with gd support, you're out of luck. It does happen less often, though.
The one thing I would love to see from perl is a standard web app bundle. Something that was a no brainer for admins to install when perl's installed. DBI, AxKit or Mason or similar...etc. Something you could count on being there. Then I could get back to a language that fits my brain better.
This is the voice of World Control. I bring you Peace.
I've been using this book for about 3 months, and I'm no Newbie to PHP programming but it's got some invaluable stuff in there.
For example,
php embeds code-like active statements in between static html. where as perl embeds HTML text in between perl commands. Each of them requires designated separators to keep the text and commands separated.
to be a little more specific, since perl had HERE statements one can have an entire perl cgi script that basically looks like a an html page:
sample perl cgi script:
print HERE1 # slashdot wont print the less than signs
this is a bunch of html here.....
HERE1
$d = 4.5 # some perl commands
print HERE2 # slashdot wont show the less than signs
more $d lines of perl
HERE2
I dont see how the separators in perl between HTML text and perl commands add any bulk or inconvnience. Yet perl can do so much more than PHP.
hence my orignal query. What am I missing here. why is there any preference for PHP? is i somehow faster or lighter weight on APACHE? (that say fastCGI is not). I'm stumped. someone please explain!
Some drink at the fountain of knowledge. Others just gargle.
This is going to sound like such a flame, but it's not, honest. What's the benefit of using something like Smarty over just not putting anything besides control flow or variable output in your HTML files? I keep all the real work in a separate file, and never have anything more interesting than for(;;){ foo } in the file with the HTML. And no HTML in the code file, ever. It's always seemed like another layer of complexity (and overhead) for very little return.
Or am I missing something?
This is the voice of World Control. I bring you Peace.
Don't usually respond to flambait, but this last paragraph is quite interesting. It seem's that history would suggest that this is not true. Back in it's glory years Netscape thought the same thing about JavaScript. They called it LIveScript/LiveConnect/LiveWire... whatever (They changed it's name in the tradtional MS fashion of changing names of a technology and pretending it's new until it finally catches on (i.e. DOM, COM, ActiveX, .NET...)). Netscape did server side JavaScript better then anyone, and it flopped (well it's actually around somewhere in the Sun's portfolio). It flopped because JavaScript (or whatever you want to call it) *is* an awful language to work in, and people would rather use any of the much better alternatives (which for better or worse often ment Java)
What was really interesting about what Netscape did was the ability to use the JavaScript on the client side to intereact with the JavaScript on the server side. This is similar to what MS can do with .NET, but Netscape was more or less platform agnostic where MS certainly isn't.
FWIW WebObjects also originally used JavaScript on the server side, and while it may still remain (backwards compatibility) it was quickly replaced with Java as the prefered language (well... actually Obj-C is and was the prefered language, but it's looks far to wierd for most people to bother learning, which is too bad 'cuz it rocks!)
--- Nothing To See Here ---
OO = Object Orientation?
Its not just EJBs that make Java a vastly more powerful
and flexible system for server-side development than PHP.
With application frameworks such as Struts, you can
quiclky develop fast and very scaleable applications. The idea
of embedding both code and HTML in the same file is very
bad practice, and makes the application both slow and
inflexible.
Java (even as JSP) allows use of really high-performance
and flexible tools such as Java Data Objects to provide
high-speed object storage even on existing databases.
(see the Apache DB project for an example).
PHP is really useful for quick development of small sites,
but so many IT projects hit problems because small sites
don't remain small, and need a better solution.
One great aspect of Java is that you can write re-usable
code in the form of beans, and use those throughout
your development environment. You don't end up writing
something for a web page in PHP and then having to re-invent
the wheel to use the code in another context.
Oh, and I find it hard to believe that PHP can match the
speed of compiled, run-time optimised and native-code
translated Java/JSP.
>>Recently I've had a chance to do some web design with PHP.
/anypattern/; } while();" as beyond their comprehension, but it's not the language's fault if they don't wanna use some the languages builtin features for their great advantage...
:)
some (?) web design (??)... how much of it to begin with?
>>Previously I'd used Perl because I'd heard from many people that Perl was the end all and be all of scripting languages for the web. Imagine my suprise to discover that PHP was vastly superior!
Perhaps your surprise came from the fact that you were using CGI Perl and that PHP was a fast Apache module? You'd be surprised to learn, though, that today there's also a Perl Apache module as well which is as fast or faster than PHP's...
>>I know this is a bold statement, but I have solid arguements to support it.
You better have them as we'll see below...
>>I'm not arguing that PHP is better than Perl in all cases. There is certainly still a use for Perl.
Actually, it's the contrary: Perl is one of the most flexible and faster high level languages in existence. It is used for nearly any tasks imaginable dealing mostly with character string processing, that is, it's an overall great general purpose Turing machine. PHP for some misterious reason is used solely as a tool for building html pages, or perhaps PDF using some commercial library...
Besides, you're aware that php was born from Perl, aren't you? They just dumbed it down so as not to scare ex-M$ users away and because of this the language just lost much of its strengh and flexibility. Ever heard of Perl's motto: "There's more than one way to do it"? It means you can express the same computation many different ways. It means, for instance, that you may express in purely procedural fashion or object oriented, where you see fit. In php (and Python as well) you're trapped in OO craze. There's just one way to do things.
Also, Perl is one of the most compact (and therefore faster) languages in existence. Of course, people's unwillingness to learn the language make them look at features such as "do { print if
So, i say, i'm not saying Perl is better than php in all cases, there's certainly still a use for php...
>>Finally, I'm not the most talented Perl programmer out there.
That seems obvious!
>>I generally prefer to use the vastly superior Python, but can use Perl if I have to.
I like Python too and highly regard it to be Perl's spiritual brother. But i wouldn't say one or the other is better. Though i would take Perl's flexibility and compactness over Python's rigid OO syntax anyday. One thing is true: they both beat the crap out of php and its VB-like stand...
>>* Ease of use. I would definitely not recommend anyone new to programming begin with Perl.
I wouldn't say ease of use is one of Perl's deficiencies. But surely the learning curve for the language is kinda steep. Still, power comes at a price and if you are willing to use a powerful tool you'd better learn how to use it and use it well.
I can say once you learn Perl right, most other languages just feel like lacking in flexibility, expressiveness or compactness.
Yes, if you never used a katana, you'd better get to grips first with a bamboo stick or something.
>> * The OO of PHP is excellent. In my experience, it rivals Smalltalk.
Who do you think you're fooling? PHP's OO features are more like Javascript than Smalltalk, stop daydreaming. If you want high level OO stuff go with Python's multi-inheritance model.
>>Hopefully Perl will be patched up so it supports such must-have OO features like introspection, reflection, self-replication and ontological data-points.
When there's real need for such features, yes. Because Perl doesn't force you into OO syntax, many constructs which just make sense in a purely OO view of the world are not really need
I don't feel like it...
I spend too much of my job re-writing code for projects
that started small and then grew.
Surely its simply good practice to design and code with
scalability and performance built in? Postgresql is no
harder to use that MySQL is it?
Apparently PHP 5 will have a "new object model." While this is good, I have to admit it doesn't necessarily inspire confidence. The basic design of the language seems sloppy as hell to me, too. It seems like at every minor release they've realize that, oh, $this wasn't such a good idea, let's implement $that to get around it/fix it. The namespace is so polluted with every little function, it's difficult to add components, etc., etc.
To be fair, PHP 5 might be a big improvement there, too.
On the other hand, it is a great language for relatively simple web scripts, and it is easy to learn.
No Java, no JSP man. Simply use PHP for web development.
Forget Java man and go to PHP!
PHP is 4 times faster than Java technology 'JSP' (Java server pages).
This tallies because compiled "C" program is 4 times faster than Java.
How on Earth was the above article modded as "interesting"? It's absolute garbage! I use both PHP and Java (and C from time to time) and Mr Coward's "statistics" have zero basis in reality. For one, C is a hell of a lot faster than Java or PHP (unless really really really badly written - like, you'd have to work hard at writing some real crap C code for it to be only 4 times as quick as Java). For another thing, it depends upon the application - Java does have an edge when there's heavy database use, due to it using a pool, rather than PHP's idea of locking a db connection to each httpd child process (which leads to the sight we see rather a lot here, of PHP sites "unable to connect to the database").
The fact that PHP is a "scripting language" should have clued AC in to the fact it's not actually "C" - it's being interpreted, which doesn't make it anywhere near as fast as C. I love PHP (used to use Perl, but never need to touch it any more - even for shell scripts) but I know it has limitations and is not always the best choice.
Code, Hardware, stuff like that.
Netscape's "solution" was proprietary and costly. They were in the wrong place at the wrong time with the wrong solution; apache was catching on quite well when they were trying to sell kilobuck server "solutions" and balkanize the web - and the geeks who spoke "web" back then (ie you couldn't walk down the street and shout to find a "web developer") spoke perl and cgi. Given the choice of supporting open and community supported vs. expensive and supporting the company that is trying to "own the internet" who would you expect to win that battle?
The reason for a templating solution like smarty is to keep presentation seperate from all the business logic. It also allows designers who only know HTML to change the template. If you keep all the real work in another file, then you are on the right road. However, I have gotten severe migraines from looking at old code that mixes HTML and another language.
Some template solutions are not much better then mixing PHP and HTML but others like Smarty are kick ass. In Smarty, you can put simple presentation logic in your templates. For example, with a proper template, you just pass an array to smarty and it will render it into a nice table, highlighting every other row, bolding keywords you tell it too, etc etc.
It does take a little while to get used too, but follow the link in the grandparent and read up on it. It is worth the time I think.
...if php would just include one tiny bit of perl goodness: "~="
Instead, I've got to write ugly crap like "if (strpos($alltext, "This string") >-1)" in order to check if a variable contains a string.
In Perl? "if ($alltext ~= "This string")". Much nicer.
The server and client are separate because processes really does run separately. It would matter what would run server-side and client-side because of the web server and browser, respectively. You're probably right that the only thing going for PHP is because it's free. However, you also left out the fact that it's open source, which means that, in time, improvements on PHP will overtake that of other languages'.
Truth is like a shining mirror that's been shattered.
I've used both MySQL and PostgreSQL. In my experience MySQL is not easier.
5) native MySQL transaction support
1. php + Smarty looks like cgi to me
2. who in their right mind would *want* to mix html with their code? When I was handed a vendor's solution with php + html mixed in a single file the first
thing I did was separate the two. How the hell can you see what is going on?
3. so much of php looks like it was lifted right from perl.
4. the real die hards are on a crusade to re-write the whole world in php. gotta laugh.
5. how come just about every site, every book on php is geared towards amatuers? I can never find any depth. Even the manual on php.net has big holes in it.
6. why are there 4 versions of the split function?
7. as for all options being compiled in, they aren't. Did you ever try to build php for the first time? You'll spend hours trying to figure out which options you should include.
For one, C is a hell of a lot faster than Java or PHP (unless really really really badly written - like, you'd have to work hard at writing some real crap C code for it to be only 4 times as quick as Java).
No its not. It really isn't - and this myth should die.
Sun's 1.4 Java VM runs Java code at only 10-40% slower than
the IDENTICAL C code. IBM's 1.4 Java VM can run Java numerica
code FASTER than the identical C code.
Don't believe me - try it and see. Just stop spreading
these myths.
Mod parent up!
"First you gotta do the truffle shuffle."
Try developing on a MSSQL database with PHP, ASP or PERL and then using an Oracle database in the production enviroment. I have seen this one too many times in my web career. With CF I is a matter of changes 3 variables to accomplish the port. With PHP, ASP and PERL you either have to change a dozen or so functions or classes to accomplish the task.
I can do that with my perl-based sites too. I change the DBI connect string in my PerlHandler, and voila, it works on all the pages.
Let's not forget that with one simple tag placed in the application.cfm, I can catch any error that bubbles up on my website, then have that error email me, allowing the user to only see an error page that I designed telling them that the error is being looked at. PHP, ASP and PERL throws the error to the webpage that the user sees. What great security that is!
That's not true either. You can catch exceptions in perl with eval and report them anyway you want. I already do this with one of my sites. I can even set it up so that when you're logged in as a certain user (developer), it will send the error message to the browser and if you're logged in as anyone else it will log the error and tell the user it has been reported.
1 - It lets you mix html and code in. Sure, it's not the only language that lets you do it, but it's still a strength.
I thought that PHP did a great job of mixing HTML and code until my PHP apps started reaching a certain size. Even using function calls and classes, templates started getting convoluted. Then I discovered Smarty and my whole way of working changed. Smarty is a template manager that allows for more precise separation of content and code. As a super-simple example, lines like become {$variable}. Over the course of a whole site, the savings from this syntax alone ease code readability (yes i care about such a thing). But there's a lot more to smarty than shorter variables, including shorthand for string modifiers and loops, as well as a nifty caching system that can speed up dynamically generated sites, and zillions of other really cool things for "lazy" programmers like me.
A lot of people on this thread have mentioned AdoDB (my other favorite PHP add-on), but I haven't seen anyone give a proper shout out to Smarty. It's made my life easier.
"Luck is the residue of design" --Branch Rickey
I find the documentation from php.net and mysql.org to be first class.
MySQL Reference Manuals:x .html
The Windows CHM manual for PHP is easy to navigate and search:
http://weblabor.hu/php-doc-chm/
PHP Documentation Downloads:
http://www.php.net/download-docs.php
http://www.mysql.com/documentation/inde
PDFs are ideal because you can search/print them easier than HTML. Plus they are free.
You're right, of course. I like dyxlesia!
LRC, the best-read libertarian site on the web
I've got a buncha linux machines here (in my home), too, but guess what I'm using to type this? I've yet to see a linux desktop environ that looks as slick and feels as cohesive as even my win2k desktop. It's been nearly ten years now - if what you say is true then it seems linux should be the most absolute kickass, user friendly desktop out there.. but it ain't, and not by a long shot. As convoluted and messy as win32 has become, the linux desktop STILL can't compete in overall "feel" with MS (much less Apple). Why is that?
it seems to me that most advocates of perl think perl is better than PHP, and vice-versa for PHP advocates.
:D
The stigma that is associated with perl is generally that "its harder, more lines of code, doesn't have the same functionality" because it takes a steeper learning curve. With PHP you can pretty much do anything right away: just search for the right function. I bet if most big PHP developers gave perl a chance, they'd be surprised.
Same goes for the other side, however. Since PHP is easy to get started on, there are a lot more PHP newbs than there are perl newbs. This reflects poorly on PHP developers as a whole, which there are obviously some very talented ones that don't deserve said reflection. I think the big thing in PHP is "controlling the beast." It can easily become insecure, inefficient, etc. if you don't know what you're doing..and the abundance of newbs make it appear like this happens all the time.
Anyway..I just ran outta pennies..
Perl to Java was a snap---the languages are so different. But moving from Perl to PHP is driving me insane. I'm guessing I'm not the only one, am I?
<a href="http://www.joblessjimmy.com">Work is dumb and so is Jobless Jimmy.</a>
Ok, I'll bite. I'm not a PHP expert, but I think I can respond to a few of these statements.
3. Huh? I don't do this when I add a module. ???
5. There is a debugger. And here.
8. There is a free PHP Accelerator for non-Windows boxes.
Just my two cents.
Smarty takes it far too far.
.php file.
It integrates far too much in a templating engine.
Of course thats just my opinion.......namely that to load one or more html template/s and perform simple pattern replacing on it should NOT require loading a 2500+ line
Whats the point of seperating the presentation logic from the main functions if you end up with a presentation layer that is 3x the size of the main program and contains twice as many functions. You lose all the benefits of templating in the first place. Especially when u have to load up a honking great class everytime to use it. As for smarty using basic presentation logic, whats the PHP doing then, just loading smarty?
I appreciate smarty has nice functions but most of them are for coders not designers, and coders don't tend to be the ones building the templates..
The point of seperating the presentation logic from the main program even though it might be 3x as big is still maintability. You should never have to go in and modify the Smarty classes. You will however have to go in and modify your own code. To me it is just calling another library for use. I don't know about you, but most of my pages are only a couple hundred lines at the most, but almost all call on some massive libraries. If I didn't want to load the libraries every time, I could hardcode some of the logic into my page, but that would increase maintanence time.
Anyways, I just got in so this post might not make sense, but even though Smarty is huge, I think what you gain in maintanability is worth it. I wonder if it would be possible to create a "Smarty Lite" with only the basic features?
Ignore what the other poster said about converting dvi. Use pdflatex to go straight from latex source to pdf. The supertabular package matches so perfectly what you asked for in your first post, that I thought you might be trolling for a pdflatex answer.
Unfortunately, as much as Perl users often enjoy faking it with multi-line regular expressions, XML is not text. What the web needs know is the successor to Perl: a language with the DOM integrated as well as Perl integrates regular expressions. And with output of structured documents as easy as printf.
I shouldn't have to be thinking about the fact that the data is marked up with tags when I'm parsing it. Instead, I should be able to concentrate on the fact that the data is a tree with subelements and attributes to each node. And I should never have to type angle-brackets when doing output.
I don't know whether XPath will be part of this language -- I haven't done enough real-world development with it to be sure. But I damn well know that the OO-structure of W3C's DOM is not the ultimate tool for the job.
I've got something WAY better than PHP, ASP, OR Pearl... ColdFusion (CF)!!! Yeah, yeah, it actually costs some $$$, but back when I was using version 1 or 1.5 is was very very cheap, around $300-$400 USD. Now it's in the 1 or 2 thousand USD range. But, the point is CF can do way more than any of the above is way less time. You can use any data type in any varaiable in any way and NOT have to cast the data type, use a integer in a string or vise-versa. Also, you don't have do declare a database connection every time, just do an entry in it's configuration using its administrative tools and you can just use the connection alias every where and even use multiple connection aliases in the same template and not worry about crossovers. CF also has open source add-ons to expand it's functionality. CF also works natively with Dreamweaver, Flash, and the new Flass connector. CF works on Solarix, Linux, & Windows. You name it, and it can be done with ColdFusion with less code in less time. No more C/C++ syntax. You can create your custome functions and even use it's cousing, CF Scripting. BTW, CF works great with Javascript. All the things you like about PHP is here, but better.
Go to www.Macromedia.com and take a look at the HUGE documentation and books. Large website use ColdFusion, even my bank, Bank Of America. VMWare uses CF also.
I cannot say enough good things about ColdFusion.
Forgot also, works with XML, SOAP, Corba, redeveloped in native Java so you can also create in JSP and it will work. Ummm, add-ons to create PDFs, built-in scheduler, built-in search engine for indexing and searching for online documents, session and client management. There are just too many things for me to list off of the top of my head.
No its not. It really isn't - and this myth should die.
Sun's 1.4 Java VM runs Java code at only 10-40% slower than
the IDENTICAL C code. IBM's 1.4 Java VM can run Java numerica
code FASTER than the identical C code.
Examples???
Code, Hardware, stuff like that.
Personally I prefer PHP Developer's Cookbook from SAMS, though it is in need of a third edition fairly soon (are you listening out there Mr Hughes). I thought it had a better organization and a wider selection of material. Just my personal preference.
Tony Williams
PHP is more than just web development. I dont know anythign about Perl or Python, but from what I have seen is PHP can do anything I have evr asked of it. Perl has been around a lot longer. You can also write desktop Apps wtih PHP-GTK just like Perl-GTK so I truly believe that this is great time to get involved with PHP. Hopefully PHP will make ASP a thing of the past soon. :-)