|
The Hitchhiker's Guide to PHP
PHP Comes of Age
by Philippe Lachaise
Now that PHP is maturing, it's time for a "meeting of the minds" between quick code-and-run scripters and UML-savvy OO developers
Few programming languages can boast a rise in popularity as meteoric as that of PHP. The now well-publicized story of a Do-It-Yourself (DIY) scripting-language-turned-IT-industry blockbuster shows that success is not always the product of methodical planning and marketing studies. But the real questions are now related to how this success will survive adoption by the big IT industry. The very fact that Oracle, among other major players, is focusing some of its attention on PHP indicates that the language has come of age.
Up until now, success just "happened." An ever-growing crowd of fans has been rallying around PHP, as if around a child prodigy. But now that the child is growing a beard and beginning to talk with grown-ups on an equal footing, are the early followers going to adapt to the change?
PHP, like most major open-source projects, is a grassroots phenomenon in the process of becoming a mainstream technology. Will PHP disappoint those to whom it owes its fame? Will it live up to the expectations of big IT?
A Tale of Two Programming Cultures
PHP's success has been attracting people from different backgrounds. The early Rasmus followers (if you will forgive the rather messianic tones that are not infrequent in open-source circles), accustomed to quick code-and-run scripting, now have to contend with UML-savvy, object-oriented (OO) programming developers intent on bringing PHP in line with other modern development tools. Both populations know a lot about Web development and have a strong culture. To ignore either would be unwise.
What does the early PHP type know about Web development, and what are her likes and dislikes? She knows a lot about design. Her taste might sometimes be questionable, but you can tell that she has HTML and CSS know-how, not to mention trendier Rich Internet Application (RIA) technologies. She's often fairly young and frequently present in PHP forums. The term "Object-oriented" probably has negative connotations for her. Her code is to the point, with rendering, not maintainability, in mind.
The UML type will be much less attracted by juggling with loosely typed variables and peppering his HTML code with
<?php?> statements. He will want to think about application architecture, class-level code reuse, teamwork, and source control. He knows that even a moderately complex Web site is first and foremost an application and that poorly designed applications translate into missed deadlines, upset customers, and even job loss.
At first glance, the latter seems better geared toward an increasingly demanding context where Web development will be more and more driven by marketing strategy and economical considerations. But should we classify the former as an endangered species? Probably not. If we accept that the Web is a very different medium than the desktop—not to mention the mainframe (remember 3270, anyone?), where dominant development methodologies originated—we may be led to conclude that, after all, there may be very good and effective lessons to adopt from this successful yet relatively unorganized approach.
Let's review the practical problems to overcome before that can happen, as well as some practical means for doing so.
Bridging the Cultural Gap
Now PHP5 is about to impose OO on the PHP world. The Zend Engine overhaul (ZE2) is taking objects into the core of the language. Not only do new language constructs encourage object programming style, but the language implementation is falling in line with other OO environments. For instance, objects are no longer copied around by default but are rather handled via references. New keywords (such as final or static) have been introduced that are only relevant to object concepts and are reminiscent of Java; other features, such as delegates, encourage the use of object design patterns. (Expect to hear talk in a few months' time about "legacy PHP4.")
This deep change was caused by inexorable evolutionary movement toward the now dominant programming model. Like it or not, the object approach will prevail because it has proven itself to be most effective for delivering complex applications, Web or not. This leaves us with no choice but to find imaginative ways of reconciling both cultures so that the design-minded and the architecture-aware may benefit from each other's strengths.
For this to happen, methodologies must be developed (or transposed from other platforms) in order to tap the versatility of the language while containing it within clearly circumscribed bounds. "Islands" of programming creativity can then exist within a strong architecture.
A telling fact is the absence of consensus around any PHP CMS or application framework, despite their explosive numbers. A recurrent complaint is that, whatever your project, no existing system will fill the bill. People start off by evaluating a few systems and regularly end up developing their own framework from scratch. Why is that?
As opposed to the desktop, where GUI design issues seem to have been settled once and for all by operating systems, the Web is a platform where original visual design does matter. Web sites carry the image and the individuality of commercial companies and may increasingly affect their revenue. Visual creativity and branding go hand in hand, so they must be facilitated.
At the same time, it must be possible to code flexible logic into the application so as to make the user experience as good as possible, bearing in mind that this user is even less likely to be a power user on the Web than on the desktop.
It's a problem when designers keep being frustrated by systems devised by programmers, as it is equally a problem when developers have to shoehorn applicative code into inadequate portal frameworks. All too often the end result is a less-than-satisfying compromise, where presentation is rather dull and much usability has been sacrificed in order to limit applicative complexity to a manageable level. (This phenomenon is not limited to PHP applications.)
To overcome these limitations once and for all, both designers and OO developers must find a way to cooperate without hindering each other's efforts. Probably the best way is to start by learning about how the other group works.
From Craftsmanship to Industry
Forget for a moment about cooperating and let us observe respective practices. Let's start in PHP historical order and pay our first visit to an "enhanced html" practitioner's shop.
The tools of the trade are very similar to those of a "pure html" practitioner: html editors with various levels of comfort and project management features and some level of integration with PHP, ASP, JavaScript, and lesser tools.
Let's take a closer look at the code for a moment. The first observation is that, more often than not, Web sites produced with this disparate assortment of tools are incredibly beautiful. We are not talking here of mere technique but of talent. Unhindered by abstract programming considerations, Web designers create visual environments that will make your clients feel at home on your Web site by playing with positive, subtly emotional effects similar to those achieved in brick-and-mortar shops by astute decorators.
Things abruptly turn bad when we look at the code with OO-trained eyes. The code looks like what it is: a one-shot, fire-and-forget job with no provision whatsoever for future evolution or easy maintenance. Quite often, it is.
Now, is it that bad? Will it be a problem later to discard part or the whole of the Web site and rebuild it from scratch? Probably not. After all, the decoration of brick-and-mortar shops is regularly torn down and built afresh. So, as far as these show-window Web sites are concerned, cowboy-style PHP programming is OK. The language is full of tricks that will help realize all kinds of visual effects aimed at capturing the visitor's attention. Object methodology is plainly irrelevant here.
This perspective changes dramatically as soon as some applicative logic is needed. Do you need a couple of forms to gather minimal marketing information about regular visitors to your Web site? If you want that information to be pertinent, you had better add validation code. While you're at it, make sure you provide filters for malicious scripts or SQL injection. By the way, since you are reading an OTN article, you must be familiar with database (DB) issues. This information that you will collect will be deposited into some DB tables, and the SELECT statements in your PHP code will reflect this DB structure. From now on, this Web site has become anchored into your business infrastructure—it is becoming a full-fledged application.
Let us leave it as it is for the present, with all its hard-coded links, hazardous type conversion, and security holes, and pay our second visit to a state-of-the-art PHP OO application assembly line. This place would seem unfamiliar and perhaps even hostile to our arty Web designer. Craftsmanship is not that well regarded here. Web development has been industrialized. To gain acceptance in this shop, you will have to become familiar with classes, inheritance, data abstraction, and a host of code encapsulation devices.
Collective discipline rules. Coding conventions have to be respected; source files must be submitted to versioning and source control. Files are organized according to a strict modular hierarchy. Risky coding tricks are banished—especially clever ones. Code must not only be legible but also well commented.
Boring perhaps, but effective. Now we are building Web applications: intranets, merchant Web sites, electronic marketplaces, all sorts of applications where a flawed design could mean going out of business. In short, we are taming complexity.
The management of the PHP OO assembly line didn't choose PHP because they loved the language. They did so because of its being as good for the job as proprietary alternatives, free of charge, and with no strings attached.
Where Do We Go from Here?
So how are we going to fulfill the potential of complementing the expertise of a very versatile language used by the early adopters with the industrial-strength methodology brought by people trained on C++ and Java?
PHP5 will upset many habits, so this question may still be premature. Some people will be forced into adopting some degree of OO methodology, and others will discover at last what OO was all about and become converts. Some niches will probably carry on as in the good old days and continue to thrive.
Let's Get Some Practice
Let us now get down to a basic, technical level and see how getting into simple habits and looking around for simple but effective solutions will help us in getting ready for changes to come. Lots of very simple conventions facilitate coding and prepare applications for scaling up.
Naming conventions (second nature to C++ coders) are the easiest means. If you already make intensive use of a code library (for example, PEAR), it might be a good idea to make its conventions your own; otherwise, make up your own in-house rules. Simplified Hungarian notation (after its Hungarian inventor, Charles Symonyi) would apply as far as loose typing permits. You may also prefix class members with underscore. Another useful habit is to append to methods (functions belonging to a class) that are not intended to be called from outside the class a distinctive prefix (for example, impl_).
Whatever set of naming conventions you adopt, make your code as explicit as possible. That way it becomes possible for a trained eye to spot a coding error in a screenful of PHP just because it looks wrong, like a blemish on a portrait.
Another crucial aspect of naming conventions is avoiding name conflicts to make reusing code on a large scale possible. Experience teaches us that programmers are not always very imaginative in the way they name programmatic objects. Chances are that there are quite a few Page classes out there, and it is not unlikely that you might want to reuse two of these Page classes that have only their name in common and serve quite distinct purposes. Bad luck. Renaming would bring maintenance problems in the long run. You'd be better off avoiding the problem in the first place. Generating a GUID would be overkill, ugly (for example, _16B280C5_EE70_11D1_9066_00C04FD9189D_Page!), and contrary to the spirit of PHP.
A simple and collision-proof way is to ensure uniqueness among in-house classes by concatenating several distinctive aspects of the class into its name (for instance, GalleryPage) and then, to avoid all chances of conflict with classes outside your control, prefix it the Java way with reversed version of a domain name you own (com_mydomain_GalleryPage).
Another habit to get into that will cost you nothing and may save your job when an unexpected application-wide change becomes imperative is to corral the most-often-used atomic statements into a unique channel. For instance, apart from debugging code, there should be only one "echo" statement in the whole application and it should be inside a function (or singleton class method). If some new context demands that output be preprocessed or redirected, you will know where to write the few lines of code needed instead of being confronted with the discouraging prospect of searching and editing a large number of files.
Error handling does not have to be as strict as in C++, where a dangling pointer or a buffer overrun may have devastating effects. When no data integrity is at stake, try to degrade gracefully by telling the visitor that something was not perfect but she should try again. An often-overlooked good friend is the standard set_error_handler() function. This is another instance of corralling—this time of atomic events—into a centralized place where all the code is dedicated to handling them. If you want to keep logs of everything that went wrong so that you can spot recurrent problems, this is the right place to do it.
Before we leave low-level coding issues, here's another lifesaving tip. With PHP5, object references will be assigned or passed by default (a reference is a handle on an object, not the object itself nor a copy of the object). As long as we have to live with PHP4, careful attention must be paid to the way objects are passed around. Some subtleties may become a cause of lost sleep. For example, the following results in $obj2 being a copy of $obj1; no surprise here.
$obj2=$obj1;
Functions will take copies and return copies unless otherwise specified—we just have to accept that. The following example has caused many a difficult bug to track:
class ObjectKeeper
{
var $_obj; // Whatever object is
function & get_object() { return $this->_obj; }
}
A reference is returned-fine. Now comes the trap:
$keeper=new ObjectKeeper();
$obj1=$keeper->get_object();
$obj1->modify();
$obj2=$keeper->get_object(); // Ask new reference to same object
if ($obj2->is_modified())
{
echo 'OK'; // this will NEVER print
}
The correct statement would have been:
$obj1=&$keeper->get_object(); // Notice "=&" instead of "="
Without the =&, a copy of the object pointed to by the returned reference is assigned to $obj1 and the state of the original object will never be affected by whatever you do to what you believe to be a proper reference. In other words, your updates will be lost.
Templates may go a long way in reconciling the culture of the Web designer with that of the programmer. They usually consist of everything that is fixed in the layout (chiefly HTML code), and template engines fill in all variable content when the page is generated. Most template engines come with a caching mechanism that ensures that the resource-greedy processing involved occurs only when a data source update mandates it.
Templates engine allow a reasonable level of separation between layout and graphics on one side and business logic on the other. The most popular may be the template engine Smarty, which also happens to be integrated into many open-source CMS and framework projects.
On the downside, it must be noted that when logic goes beyond basic search-and-replace substitution, template engines tend to propose programming dialects. It is more than likely that the way of the future lies with XSLT technology, and extensive XML support in PHP5 will change many things in this respect.
Last practical aspect but not least: the reuse of first-grade code from well-known libraries. We will limit our study to PEAR, since it is now part of the standard PHP distribution.
PEAR might be what currently comes closer to genuine standard PHP software components. Strict contributors' selection and quality standards ensure that components are as good as commercial ones would be. Versioning conventions give you fine-grained control over which versions of a component are suitable for your application. PEAR offers a rich array of functionalities, ranging from form handling to database abstraction layer (PEAR::DB) and including such advanced features as Web Services or WebDAV support.
Needless to say, you may save quite a few days of intensive R&D work by getting familiar with PEAR and similar PHP code libraries.
PHP5 on the Horizon
PHP has established itself as one of the biggest open-source success stories, along with Linux and Apache. Despite all its imperfections, it has already gained a strong foothold in the IT industry and still enjoys its huge grassroots community of users.
PHP5 will probably prompt the development of heavy-duty Web applications, with more and more of the business logic layer that interacts with databases being entrusted to PHP code. At the same time, agile coding methodologies will make increasing use of XML technologies to make it much easier for Web designers to collaborate without friction with developers and software architects.
Expect a new generation of very attractive and usable PHP-based Web applications.
Philippe Lachaise (plachaise@virtualmice.net) started with IT in the mainframe environment of the mid-80s. Moving to specialized translation of computer software, he started programming seriously to build translation productivity tools. An early adopter of object technology, he has since had experience with various flavors of object application development.
|
Bookmark
