Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Michael J. Ross writes "Web 2.0 applications and sites commonly employ a number of technologies: PHP, MySQL, XHTML, CSS, JavaScript/Ajax, microformats (standard formats for HTML data), tags (keywords for categorizing site content), and Web feeds (formatted and streamed Web content, usually in XML, such as an RSS feed). Because learning and using most of these technologies can be rather challenging to a Web developer, perhaps the best way to get started doing so is by using all of them to create a single Web-based application, with no pretense at mastering any one of them. This is the approach taken in Quentin Zervaas's book, Practical Web 2.0 Applications with PHP." Read on for the rest of Michael's review.

Practical Web 2.0 Applications with PHP

author

Quentin Zervaas

pages

569

publisher

Apress

rating

7/10

reviewer

Michael J. Ross

ISBN

1590599063

summary

An example-based guide to PHP and Web 2.0 technologies.

The book was published by Apress, on 20 December 2007, under the ISBNs 1590599063 and 978-1590599068. On the book's Web page, visitors can read and submit errata (apparently none, as of this writing), read the online table of contents, download Chapter 11 ("A Dynamic Image Gallery") as a PDF file, and purchase an electronic version of the book.

Given the number and complexity of the technologies discussed in the book, it is little wonder that it is 569 pages long. There is certainly a generous amount of material, and it is grouped into 14 chapters: planning and designing the sample application; application framework setup; user authentication, authorization, and management; user registration, login, and logout; Prototype and Scriptaculous; page styling using CSS; creating a blogging system; extending the blog manager; personalized user areas; Web 2.0 features (tags, Web feeds, microformats, and public profiles); the image gallery; site search functionality; integrating Google Maps; deploying and maintaining the site.

The first two chapters set the stage for the rest of the book. Chapter 1 provides a brief overview of Web 2.0, the sample Web-based application to be developed in the book, database connectivity, search engine optimization, PHPDoc, templating, and security, as well as the major features of the sample application, namely, a blog site. Chapter 2 describes how the reader can set up the application framework needed to follow along as the author explains how to build the sample application. This includes brief descriptions of how to install Apache, MySQL, PHP, and the Zend Framework. In fact, the book makes so much use of the Zend Framework that, after reading it from cover to cover, the reader will have gained a strong understanding of how some of the most popular components of that framework can be employed in their own projects. The chapter describes the file system structure the author has chosen, how to configure your Web server, how to set up the database, and how to connect to that database. It also provides an introduction to the Model-View-Controller (MVC) design pattern, as well as the Smarty template engine — both of which are used later.

While the introductory material in the first two chapters is essential — particularly to any inexperienced programmer — and generally spot on, some of the material could use a significant amount of expansion and clarification. For instance, in Chapter 2, the instructions on how to configure one's Web server, could easily prove confusing to most readers, because the author refers to the IP address 192.168.0.80, with no explanation as to what it is and how it relates to the usual local Web server address, 127.0.0.1 (localhost). His recommendation for a "hosts" file entry, "192.168.0.80 phpweb20," certainly does not help clarify matters. Furthermore, the author does not explain why "phpweb20" should be used instead of "localhost." In the subsequent discussion on virtual hosting and Linux, in a "Note," he mentions that the reader "must have previously included the NameVirtualHost 192.168.0.80 in your main Web server configuration..." In another note on the same page, he provides instructions on the PHP setup that should have been included earlier, in the section on installing PHP. In general, there are too many instances in the early chapters where key information is presented not where the reader would need it, but pages later. This can be especially exasperating to readers who are fairly new to the technologies, and are trying their best to follow the author's examples, every step of the way.

Chapter 3 discusses user authentication, authorization, and management. Unlike most PHP books, this one does not limit the reader to using MySQL as the relational database management system in conjunction with the sample application. The downloadable code for the book makes it possible for the reader to use PostgreSQL, even though the text itself focuses on MySQL. This flexibility is made possible by the author's use of the Zend_Db class. Admittedly of little significance, some of the book's SQL code looks a bit puzzling in some places. For instance, on pages 46-47, unneeded blank lines are contained within the "create table users" statement, with no reason given. Of greater importance, the chapter includes a short but valuable section describing the potential problems of date and datetime values in MySQL caused by server time zones, daylight savings, etc. — a topic well worth reading up on. The fourth chapter explores user registration, login, and logout functionality. Crucial topics such as password reset are covered, while some others, such as password strength, are not — no doubt due to space limitations.

Ajax is considered a central part of the new Web 2.0 trend, and for doing Ajax, the author recommends Scriptaculous, which is based on Prototype — both introduced in Chapter 5. The basic CSS styling of the sample application's Web pages, is covered in Chapter 6. The only flaw in the sample CSS code is that the author formats the declarations within each rule inconsistently, with some rules having multiple declarations on a single line, and others having each declaration on a separate line, which most people find easier to read and maintain. A highlight of the chapter is the author's comparison of the advantages and disadvantages to using a print-only CSS stylesheet versus a dedicated secondary print page — a topic not even seen in Web programming books that focus on design and CSS. The chapter concludes with a discussion of client-side form validation using JSON.

Chapters 7 through 13 focus much more on the sample application's functionality: implementing the user blogging system, and supplementing it with a blog manager index, Ajax capabilities, and a WYSIWYG editor (FCKeditor); creating user areas that can be customized by the users themselves; implementing the aforesaid Web 2.0 features (tags, Web feeds, microformats, and public profiles); implementing a dynamic image gallery, using GD for resizing, etc.; adding site search capabilities using Zend_Search_Lucene; incorporating Google Maps into the users' public blogs. All of these chapters are chock full of sample code, which the energetic reader may want to test out in their own development environments — particularly if they want to follow the author in creating the sample application. Fortunately, the reader will not have to waste any of that energy typing in code, because it can all be downloaded from the author's book site.

Specifically, Chapters 7 and 8 are devoted to the blogging capabilities of the sample application. While the discussion of permanent links, filtering, and the FCKeditor WYSIWYG editor may be of interest to a reader not implementing blogging themselves, the book at this point becomes more narrow in the information that it conveys — focusing even more on the code of the sample application. After reading through dozens of pages listing the code for blog entry management, readers may begin asking themselves, "Why not just use a CMS, instead of reinventing the wheel?" It should be borne in mind that the point of the book is not to advocate reinventing the wheel, but rather to show how a sturdy and reliable wheel can be built. Nonetheless, readers will need fortitude to plow through the many pages of code.

Despite the obvious expertise of the author, readers should be alert and open-minded to potential pitfalls. In the sample application's code, for generating passwords, the author uses only a hash function, md5(), despite its vulnerability to rainbow tables. The reader is advised to use an encryption function instead of — or in conjunction with — any hash function. The book contains another example of inattention to data security: In Chapter 4, as part of the user registration process, the user's password is e-mailed to the new registrant, naturally in plaintext, making it visible to anyone who intercepts the e-mail message. Years ago, all sorts of online organizations were following this lamentable practice; fortunately, "nasty grams" from security-savvy users seem to be turning the tide.

After exploring the possibilities of dynamic image galleries and Google Maps, the last chapter may appear relatively uninteresting to the reader, because it discusses application logging, error handling., and Web site deployment and maintenance, including backups. These topics may not seem too exciting, but failing to take the lessons to heart, and then experiencing a heart-stopping crisis on one's production site, will be the kind of excitement no Web programmer wants to experience.

What distinguishes this book from the majority of other PHP titles — for better or for worse — is that the author makes extensive use of specific frameworks and other tools, such as the Smarty templating engine and the Zend Framework, as well as classes that he has written, which are freely available in the source code. As a result, the value of the book to the reader is, to a certain extent, proportional to how much that reader wants to learn and possibly use those components. For example, if the reader chooses, for whatever reason, to not use the MVC design pattern and the Zend_Controller class for implementing MVC in their application, then the author's use of these will appreciably reduce the value of the book to that particular reader. In fact, given how lengthy Chapter 2 is, such a reader may mistakenly conclude that the rest of the book would be of no greater interest to them, and consequently become discouraged and quit reading. Other examples include the homebrew DatabaseObject and Profile classes, discussed in Chapter 3. Regardless, some readers may find that even if they do not use the author's chosen tools for their own applications, there is enough other programming and application-focused information that makes the book worthwhile to them. Other readers will be disappointed in the overall value of the book should they choose not to follow the author's recommended approaches. In addition, some programmers may be quite hesitant to base one of their own applications — particularly for paying clients — on classes created by a single developer, with no accompanying unit testing code to verify its soundness.

In terms of the production of the book, it is definitely up to par, with a font that is readable and yet small enough to get plenty of information on each page — in conjunction with the bottom margins being utilized better than in other books. However, at least for my particular copy of the book, several blocks of pages were cut with different widths, making it appear as if one or two blocks had become detached from the glue binding, when in fact they were all well attached. Within the binding glue, they were all attached at an equal depth, indicating that it was the cutting of the pages that caused the problem, and not how the blocks were set in the binding.

Even though some readers may find the book overly focused on particular frameworks and other tools, Practical Web 2.0 Applications with PHP is an instructive and expert demonstration of how to use PHP, MySQL, the Zend Framework, Smarty, Ajax, and other powerful technologies for creating robust Web sites.

You're probably going to get modded into oblivion for that, but I find that it has a lot of truth. Compared other web development technologies like.Net and Java, PHP seems really unorganized and difficult to program in. Everything under the same namespace is probably the most annoying part. Next is that fact that there's about 7 different ways to do everything. I have yet to find a good IDE that does autocompletion (intellisense) for your coding. And with an API as disorganized as PHP's, I would very much appreciate it.

Sure it takes a while to get the hang of the nuances in function naming and parameter ordering, and even now I still need to lookup some functions in the manual, but for most purposes the auto completion in Eclipse PDT works well - it fully supports auto-completion for user & system code along with classes and javadoc/phpdoc style documentation comments.

I tried ZendStudio and their Eclipse project. Last time I checked, it didn't have autocomplete/intellisense for the functions that were part of my code at least the ones from other files that had to be included. I seem to remember it working for the core PHP functions, but not for any of the code I had actually written. Despite how much I don't like Microsoft's server products, VS.Net is an amazing IDE.

First thing I do with any IDE is turn off auto-completion. I find that my fingers have already typed the entire function name and hit space before my eyes register that the stupid IDE has replaced my text with some wrong guess. Stupid, stupid concept right from the word go.

Most of the time I've typed 5 or 6 characters and the auto-completion engine in Eclipse picks up the most used functions and lets you continue typing, meaning most of the time I type only half the functions name then hit the enter key to continue in the the arguments while at the same time popping up a reminder of which arguments and their types that it expects.I've found that it doesn't get in my way and most of the time I it speeds up the manual labor part of writing code, it lets me express my ideas quic

I haven't used it myself, however Aptana Studio [aptana.com] has been recommended to me. It's based off Eclipse and does CSS, JS, HTML, PHP, RoR it has a JSON editor and has a bunch of Ajax libraries built in.

Difficult to program in?? Try figuring out how to use a certian function or class in.Net and you have to navigate the *horrid* MSDN site. Conversely the PHP.net site is fast, easy to search and navigate, and has tons and tons of helpful user comments on each item. I haven't found anything that comes anywhere close to the online PHP.net reference for any other language I've used.

Add to that, the massive headache that new.net users face (I was one last month) when getting set up. Configuring their own PC, the IDE, all the libraries and packages and then getting Visual Studio set up. Compared to PHP, you grab a cheap PHP web hosting provider and a friggin text editor or the IDE of your choice and you're running a hello-world in under 10 minutes.

Add to that the massive library of FREE addons, libraries, scripts and opensource projects that you can learn from or incorporate... and I'd say the massive number of PHP newbies out there indicates how EASY it is to use. Did I mention free? And open - as in not tied to the whims of one corporation.

I'll refrain from listing good IDEs since I see another responder has done so.

You don't have to navigate MSDN. You put your cursor on the desired function, and press F1. Alternately you can search for the function/class name, and it usually shows the correct item in the first 3 or 4 results. With.Net, you get all the documentation on your local machine. No need for a net connection. I will admit that the user comments on PHP.Net are nice. However, a lot of the comments are just useless, and don't really offer much. With.Net, you can install the free IDE, and there's no configuration necessary. It even has it's own web server that it installs. You can edit the code while debugging and changes take effect immediately. You can even rewind from an exception that has already happened, fix the problem, and continue on debugging, without ever even stopping. Try getting a debuggable PHP install working on your local machine, and compare that to the ease of installing VS.Net. You can also get a lot of cheap hosting providers that support ASP.Net now.

You don't have to navigate MSDN. You put your cursor on the desired function, and press F1. Alternately you can search for the function/class name, and it usually shows the correct item in the first 3 or 4 results.

Replace F1 with F2 and Eclipse with PDT does the same thing. phpDoc is used very similarly to Microsoft's way of being able to comment code.

Also the GP who promoted Java; it's now very easy to use Java functions from within PHP, so if you require Java it's no problem to use it from directly within a PHP app. Also PHP6 will bring namespaces, so I think all of the gripes about PHP I've seen so far in this topic are outdated.

Just because they've introduced namespaces as a feature in the language, doesn't mean the entire API gets organized using namespaces.

So this means the namespace argument is bullshit. You don't get a good API just because you have namespaces, but also you can have a good API without namespaces. Seems like if people need strawman arguments to bash PHP it can't be that bad.

-Install.NET 3.5 (likely already installed on your windows box through windows update)-Install VS2008 Express (comes with sqlexpress, no setup necessary for it seperately)-Start programming, with intellisense help (web apps, console apps, windows apps, etc)That's quite hard! No web server to install. No "15 different libraries all to talk to the same database". No "now install 15 different libraries, all of which take parameters in different orders and have differing semantics". Etc.

For when I must dirty my hands with PHP, I use Visual SlickEdit which has great auto-completion (and many other) facilities for PHP + a ton of other languages. Heck, it was even simple to add autocompletion support for nwscript, the scripting language used by the game neverwinter nights/neverwinter nights 2.

Compared other web development technologies like.Net and Java, PHP seems really unorganized and difficult to program in.

Have you ever coded in Perl? I remember the first time I saw Perl:

Me: Hey Bill, you know when I asked to send over some perl scripts for me to learn perl, I think it got messed up. Part of it looks encrypted or encoded or something.Bill: It's not encrypted or encoded. That's how perl usually looks.
*My head explodes*

Then open Eclipse, go to the workbench, and in the menu, do Help > Software Updates > Find and Install, then choose to Search for New Features to Install, then choose install from archive and point it at the plugin you just downloaded. It will tell you it needs to restart afterward.

Now you have a functional IDE, and you can use Window > Show View > Other to choose whatever panels you want to have open in your workspace. I mix and match Aptana and PDT.

Last but not least, you need the Zend Debugger. Do Help > Software Updates > Find and Install, then do Help > Software Updates > Find and Install, then choose to Search for New Features to Install, then choose New Remote Site. For Name, put Zend Debugger, and for URL, put http://downloads.zend.com/pdt [zend.com]. Make sure that site is checked in the list, then click Finish and it will search for your debugger. Find it, install it, then do go here:

Perhaps, but features of a language can increase or decrease the difficulty of reading and comprehension.

Keyword "generally". I've got several small apps that exist as single PHP files. Forcing separation (or even OOP) here is not a good thing, it's pointless and stupid.

Well, PHP was originally a templating language:) In fact, the common problems I have with it are when there's more PHP than HTML. When used as a templating language, it's just fine, and it makes sense for it to all be in one file. Other times, I'm not so sure, but I'd be hesitant to say that there's NEVER a time when one file doesn't make sense--it just usually doesn't. PHP's

Java is worse than PHP? Because of *that*!? For one, I think you meant to say, "Why is this code using Hashtable instead of HashMap," or perhaps say, "Why is this code using Vector instead of ArrayList?" For anything since Java 1.2 (many years ago), you should only be using Vector or Hashtable for legacy code that must work with very old VMs or if you need to access the data structure from multiple threads. Pretty straightforward to me as any Java programmer worth their salt knows this.

For building web apps? Facebook might disagree with you.
The people who start the PHP/.NET/Java flamewars somehow almost always forget that PHP is a language solely designed for building web sites, whereas Java and the.Net framework are not. Java and.Net can build web sites, but if you're going to compare them, you need to compare them on that level.

For building web apps? Facebook might disagree with you.The people who start the PHP/.NET/Java flamewars somehow almost always forget that PHP is a language solely designed for building web sites,

I would say that it is good for building web *sites* but not so much web *apps*. PHP is fine if all you need is a little dynamic content here and there, but for applications it falls short, IMO. PHP is a bland, unexpressive language with a bunch of modern features such as OO bolted on as an afterthought.

I would say that it is good for building web *sites* but not so much web *apps*. PHP is fine if all you need is a little dynamic content here and there, but for applications it falls short, IMO.

That's a pretty good way of looking at it. Usually, I find that PHP makes for unmaintainable code. Simple websites don't have this problem, but then, simple websites sometimes grow up to be large ones.

Oh well, not really interested in a PHP flamewar. Suffice it to say that ever since I've discovered Ruby and Python, I don't want to touch another line PHP code again. I don't care if you do dress it up in some MVC framework, it still looks like a turd to me.

Well I hate Rails vehemently, but I'm liking Django (an MVC framework for Python.) Both have limitations, though. I used to think that a PHP MVC framework might be ok, but then I remembered that a lot of the things that I hate about PHP would still exist.

Something I find funny about PHP is that someone actually wrote a templating language for it (Smarty). I thought PHP WAS a templating language!

That's a pretty good way of looking at it. Usually, I find that PHP makes for unmaintainable code. Simple websites don't have this problem, but then, simple websites sometimes grow up to be large ones.

That's a programmer problem, not a language problem. It's just as easy to write understandable, maintainable code in PHP. PHP gets a bad reputation because it's so accessible to newbies, who write bad code. But in the hands of an experienced programmer, it's no different than any other language.

Well I hate Rails vehemently, but I'm liking Django (an MVC framework for Python.) Both have limitations, though. I used to think that a PHP MVC framework might be ok, but then I remembered that a lot of the things that I hate about PHP would still exist.

You should take a look at Zend's PHP framework. There are a lot of other ones out there too.

This happens all the time. People take a perfectly reasonable tool and try to apply it in ways for which it was never designed. Then the developers add features to make those uses easier, and you end up with a crappy tool that does the job.

This is very true. However, Smarty is supposed to remove presentation from the programmers. So if your bus

That's a programmer problem, not a language problem. It's just as easy to write understandable, maintainable code in PHP. PHP gets a bad reputation because it's so accessible to newbies, who write bad code. But in the hands of an experienced programmer, it's no different than any other language.

Frameworks help a lot. The problem with PHP is that everyone ends up writing their own quirky framework. But even then, PHP as a language is somewhat unexpressive with an object model that feels bolted on as an aft

PHP is a language solely designed for building web sites, whereas Java and the.Net framework are not. Java and.Net can build web sites, but if you're going to compare them, you need to compare them on that level.

Is that to imply that something which is specifically built for a purpose is always better at said purpose than something which is built for a broader range, including the purpose in question?

Is that to imply that something which is specifically built for a purpose is always better at said purpose than something which is built for a broader range, including the purpose in question?

Don't be ridiculous. Nowhere did I imply that, or even say which one I thought was "better". I said you need to evaluate them on the same level, ie. their ability to build web applications. You wouldn't compare a 3-in-1 Printer/Scanner/Fax to a Laser Printer and say "The 3-in-1 has more features, so it's better at printing."

What I'm pointing out is that the features of Java and.Net are often compared to PHP in a broad view when that doesn't make sense, and it's something you have to be careful of.

This is basically how I learned PHP. Without any PHP or mysql experience or even understanding the concept of a loop, I used tutorials from webmonkey.com and made cobbled together a weak CMS system over the course of a couple weeks. When I finished I immediately wanted to start over using what I'd learned.

Most of the tutorials on the web show the wrong way of doing things. Want to connect to MySQL? The tutorials say to use MySQL_ functions, and the really good ones tell you to use mysql_real_escape_string to ensure that don't subject yourself to sql injection attacks. Most of them leave this out. The best way to actually do it is to use PDO with prepared queries (not talking stored procedures here) so that you don't have to remember to escape your strings, and plus it speeds up queries a little. You also get the added advantage of not being tied to MySQL. Because of the terrible quality of most of the tutorials, most PHP programmers never learn the right way of doing anything, and when they do, they feel like going back and redoing all their work, because the way they did it before was so poor. I've done it myself a few times.

I think best practices and the ideal implementation in your code is beyond the scope of a tutorial or a book. You're not expecting to finish it and be an expert. Tutorials are a great way to get practical knowledge (something you won't get much of in most classes (not that they don't offer other advantages)). I think any text that attempts to introduce every single such detail would end up with most of it being lost on the reader and what would have been simple enough becoming convoluted. Learn the language, then learn to make best use of it.

The best practices and ideal implementation should be the only thing covered in the books/tutorials. If you don't have room for multiple implementations, you should at least include the most correct solution.

I think best practices and the ideal implementation in your code is beyond the scope of a tutorial or a book.

Personally I can't think of anymore more in-scope for a tutorial book. There's already enough of worthless "tutorial" books that cobble together a useless example and then just cat a bunch of man pages together to pad out the rest of it (in fact, we seem to get a "review" of one of those every couple of weeks here on slashdot).

I concur. The signal-to-noise ration of most tutorials on the net is abysmal.

To figure out how to do things, I started piecing together tutorials, to make things just work. To really figure out how to do it right, I started disassembling code from large, popular hacking-targets such as Wordpress.

One of the worst examples I ever saw was somebody asking how to make a timer go off at a specific time. In.Net, the timers can only be programmed to fire after x milliseconds. So the response was to fire the timer every second, and then check the time, to see if it was the time you wanted it to be. The correct solution would be to just set the timer interval to DesiredTime.Subtract(Now).TotalMilliseconds. However I went to about 15 different sites before I decided to create a better solution on my own.

This comment is especially infuriating. Most PHP tutorials were written back when there was no other way to connect to a MySQL database other than using mysql_connect. PDO was only recently added to PHP. I guess someone on the internet should invent a magical program that automatically updates every tutorial ever written whenever the geniuses over at zend make a change to PHP. Oh wait, it would end up in a neverending loop.

PHP 5 is great and all, however many of the cheap hosting plans that make it so popular are stuck with 4. This means all the web tutorials cater to the lowest denominator, and this is PHP4 and the MySQL functions.

It was hobby work, and don't worry -- 8 years later I definately understand the concept of a loop. The tutorial I used assumed, I would imagine, that you already knew what a loop was. Maybe I skipped a tutorial or 2, I don't remember. I was able to recognize that, "hey, it's doing the stuff in this code once for each row my query returns!" and use it accordingly.

CMS might be a little kind. I was able to post stories and people were able to leave comments, along with admin and registration pieces.

Glad to hear it was hobby work. Extending yourself and trying new things in a safe environment is exactly what an IT professional should be doing.My first experiences programming were....amusing. I still remember at age 7 or so I got my first computer - A Texas Instruments 99/4A - and not knowing whether or not a typo in the code could blow the thing up.

Then there's the fact that mouse droppings in my Apple IIe hard disk was causing disks (including my backup disks) to get wiped. I was writing my first game

A little off on a tangent, here. But I've never seen this addressed in any of these "Web 2.0" books. Has PHP ever introduced anything that is the equivalent of ASP.NET's "Master Pages" [microsoft.com]? That's one of the few innovations that I really liked about asp, and the last time I checked, php still didn't have anything quite like it (it was a godsend for me as a developer/designer).

PHP is a language, ASP.NET is a framework (you can use different languages inside of it).

The question to ask is "Have any PHP frameworks introduced or adopted concepts like 'Master Pages'?".

Short answer is that I don't know. However, you'd need to look at things like symfony, codeigniter, cakephp, zendframework, and others. My guess is that no, those frameworks don't have any concepts like 'Master Pages', but I'm not an expert in those frameworks.

Well, yes that is true. But in application they seem to serve similar functions (once you decide what language you're using in PHP). Dynamic server-side content would seem an ideal way to separate layout from content (much in the way CSS separates formatting and content), yet ASP's Master Pages seems to be the only implementation of this simple idea (can't believe it has taken this long for someone to come up with something that would seem so basic). I always expe

There's plenty of frameworks out there specifically for separating content from layout. Just look in http://pear.php.net/ [php.net].

I know nothing of ASP or its Master Pages, but when it comes to said separation, I favor HTML_Template_IT for its simplicity. For those who want a more "involved" templating system, there's things like Smarty, which I think doesn't quite have as strict a separation as I'd like.

I've used something similar to yours, but with different types of content (not processing), some pages would have extra content that needed some extra styling. I just split the file in 2, then do a test for 'mycontent_extra.php' to see whether I should load these.

It's not pretty, but it is flexible.

That's how I feel about PHP as a whole.:-)

When I discovered Python after PHP/Perl I was hooked... much cleaner, much easier to read, and there should be only one way of doing things - the right way.But you still can't beat PHP when it comes t

Ug. Look, Microsoft did not invent the 'master page' idea. They took a common concept - templating - and gave it their own Microsoft Name and implementation method. And then they spout it like it's some kind of great new invention.From what I can tell, it is equivalent to having each of your PHP pages include a header and footer into each page.

If it's like master pages in Expression Web, then that's not quite right... Instead of calling a separate file for the header/footer/etc when the page is generated, the page is kept static.

When you modify the master page, there are areas of the page that you designate as editable regions, and so when anything outside these editable regions is updated in the master page, the change is replicated on to each associated page.

This is assuming these master pages are similar in functionality to the 'dynamic

That's a really oversimplified example of templating. Templating usually allows you to be more specific--rather than just "inner page content" you can have much smaller bits of dynamic content. In its purest form, your HTML page looks like HTML, but essentially has variables for content (without markup or scripting) that gets replaced on the fly.

The purest form isn't always the best way of doing things, but a good rule of thumb is that the more that your template handles, the better.

The concept is called templating and used to be called 'Server Side Includes' (somewhere around 1997 or so... ). ASP, JSP and PHP are originally SSI languages / templating languages.And if you want to use templating for your web developement - which is discussion worthy in itself - anything other that TAL (Pe(rl)-TAL [cpan.org], PHP-TAL [motion-twin.com] or 'original' [owlfish.com] TAL [zope.org] is completely pointless, because the above mentioned languages are nothing but templating solutions in themselves. There is no point bolting another layer of that on

... PHP-TAL... There is no point bolting another layer of that on top of them. Which is why I strongly dislike Smarty and it's ilk.

PHP-TAL is the same as Smarty just with a different syntax. And much more code in the generated templates. A short 11 lines template, which outputs data in a table gets a 18 line compiled template and smarty, while PHP-TAL needs 40 lines to do the same. And I don't need a benchmark to see PHP-TAL produces slower code with all the function calls and controller classes.

TAL (Template Attribute Language) stores it's signals in it's own tag attributes. Hence the name. This means you can build a template filled with mock-content that renders perfectly in any browser without the SSI enviroment and as soon as you integrate it into the templating layer the demo content is automatically replaced by the generated content. A feature pure PHP, JSP, ASP, whatnot code definitely can't provide.

[ Using extrans mode, so I'm quoting old school style here... ]Qbertino> There is no point bolting another layer of that on top of them.

Hear hear!

All these freaking template languages just re-invent the wheel for the most part. PHP *IS* a template language first and foremost, that's what it was designed to do, that's why we can intermingle PHP with other stuff in the first place. What the hell is wrong with...... how is it any worse than
{loop y as x} {echo x} {/loop}and other such cons

[ Ahh fuck. How did I do that. Changed it to POT mode before I submitted. Habit. Let's try that again. Wish/. would allow editing posts Digg style. Filling in time because of the annoying required delay. Using extrans mode, so I'm quoting old school style here... ]Qbertino> There is no point bolting another layer of that on top of them.

Hear hear!

All these freaking template languages just re-invent the wheel for the most part. PHP *IS* a template language first and foremost, that's what it was des

As someone who works for a.NET company and does freelance work in PHP, I'd suggest that include()s tend to be just as if not more effective, depending on your development style. Of course I'm not the slightest bit experienced with.NET (and even less so with VB/C#, though I could probably pick up the latter in a weekend if I was bothered, given my background with C) and probably am doing it wrong, but my experience with.NET and Master Pages tends to give me a ton of half-assed template files and messy UR

What do master pages have to do with URLs anyway? And for URLs, ASP.NET has URL mapping built in if you want "pretty" ones. And if the URL mapping features don't do the trick (let say you wanted a complicated scheme), 6 lines of code in an http handler will do it.

Also, C# is probably as close to straight C as Python is to Smalltalk: not very (aside maybe for the brackets)

Master pages were actually created in response to the fact that doing includes or "components" (to keep your header and footer logic/presentation centralized in one file) was somewhat painful. It's once again hit the magic MS bar of implementing an idea so far, but no farther. If you look behind the scenes at a number of PHP packages (phpBB3 comes to mind) you will see a full (real) templating system built-in that goes beyond the basic "surround the content with some stuff" that master pages gives you. At t

I believe what he is hinting at is the fact that PHP, unlike the ASP.NET framework, does not provide functionality on that level. Instead it is up to you to create that functionality, or use a framework where someone else created that functionality for you. Implementing the Master Pages feature in PHP would be a trivial task. You could recursively evaluate templates, capture their ouput, and place that output in the proper location on a parent template, or you could composite the entire thing into one te

The reviewer suggests encrypting the password. Well, storing a hashed version of the password is at least a step in the right direction. Storing a salted hash is better, though. Encrypting that salted hash would be another level of security, although I don't think it'd buy you much more than salting it.

When you're storing passwords, you almost never need the actual password anymore. What you need is a one-way function that can be used so when the user enters the password, the right bits come out (that match the original).That may be md5, crypt, or whatever, but multiple methods are always better. And it has to be deterministic (ie: the password goes in, and the result is always the same).

If you do need the password later (because you need to stash it for enabling access to other systems), your options are

I'll have to concur with this approach. A lot of times with web apps on shared hosts, you don't have the option of saving your config files (with your database config) somewhere 100% secure, and many of the more ghetto Win-based shared hosts give global read permissions on everything for every account on the box, even if you've got a home directory to save to outside of public_html/ or whatever.Anyhow, what this leads to is you have to assume that your database config isn't even vaguely secure unless you've

Yet another guaranteed entertaining flamewar! Hey all you science, art, IT and politics geeks, let's all go watch the programmers burst a blood vessel over how much they hate PHP! It's guaranteed to be a great fireworks display! I got beer and pretzels, you all bring chips or cheezy poofs.

Personally, I learned PHP over the years by creating simple web applications for various tasks and eventually because the web applications required more and more as they got more complex I was able to slowly and methodically work my way into a private framework I coded myself.This book, like many other skips over this whole learning process. To really teach a language, any language, you have to explain why you do things as well as the goals.

I like how they didn't even bother tagging this article with any of the useful tags, like say "php". Usually a new article starts with a few practical tags, then "slashdottagsmakemesmile" type things show up.

I guess this is the forward progression of Slashdot tags: no attempt at useful tags.

Say what you want about any language, any database, any scripting... but I have always said: if you have decided that you want to learn that language, then first find out what its capabilities are (do your best to understand their limitations), but come up with a big project that you want to do.

That is how I learned PHP, Javascript, and SQL simultaneously. I decided I wanted a web site that was database-driven and would stream MP3's. I knew what needed to be done, but I didn't always know how. I found people's examples on PHP.net very helpful, and went off on all kinds of tangents reading "Oh, hey if you have this situation, watch out for this...."

Now I can actually do stuff without having to look up function names all the time (though I still have to occasionally).

What did it get me? Well it got me off the telephone with a nice paying job that nearly doubled my salary, and to-date I'm about the best guy I know who does this sort of stuff. (Please don't take me wrong... I know there are people far more proficient at this than me; I'm not saying I'm the best -- just better than 90% of the industry out there, and I am creating useful things.)

i learned a lot of these Web 2.0 techniques by doing them myself on my own site [greenis.us]. if you're trying to pick up on all this in cubicle-land, it's going to take a long time to get up to speed. things as simple as RSS feeds can be become quite complicated if you're using a huge legacy content management system. things like AJAX are hard to effectively introduce into a mature J2EE web app.

i knew nothing about RSS feeds, and after a quick read at google I was able to add RSS to my site and get it online in un

I've been a web developer for about 12 years now, and have worked with.net, asp, php, CGI and so on over the years.

From my expierence of learning new languages and techniques as well as teaching others who are new to web development with such techiques as AJAX; learning off a full blown app with all the bells and whistles all ready added makes it difficult and even more challanging. Many times the code can be misleading and often confusing (most AJAX code I have worked with has been a nightmare) and can often lead to most people not learning but instead simply doing copy/paste of code snippets and simply relying on the fact of "this piece of code works with this form, it will work on this form also" type of mentality of programming.

Don't get me wrong; I am a firm believer that the best way to learn how to program is by trying pre-existing apps that are around to get your feet wet and to see things in action which many of the chapters in the book touch on (authenicating users, user logins) but for many people who are getting into programming IMO planning and designing and application frameworks are not the type of thing anyone should focus on first. How can you start to learn about designing a web application if you have had hardly any expierence with the language itself. And even more so with PHP as this is the gateway drug; er language many people are starting off with in their first step into programming.

Totally agree with you there, and I'm having exactly that problem in my current work place... They've been doing Ajax since a few -months- after the introduction of the XML HTTP active X in internet explorer for Outlook Web Access, something like 6-7 years ago, long before the word AJAX came out...So even though Im fairly knowledgeable in virtually all mainstream or semi-mainstream web technologies of the past decade, from raw C with CGI Bin to.NET with ASP.NET AJAX, I'm looking at the code going "WHAT THE

PHP sucks, but none of its problems are showstoppers. You do have to look up every strwtfbbq function to check needle/hastack order and if someone decided to throw in underscore for a good measure, but after you do that (and go through three dozen application-breaking retarded configuration options) it works, works well enough and scales nicely on loads of different systems and servers.