PHP has matured _php Digest

because PHP is maturing, it's time for a quick, out-of-the-box scripting person to agree with the object-oriented developer who understands UML.

Few programming languages can be popularized as quickly as PHP. Now widely publicized stories about do-it-Yourself scripting languages that change IT industry show that success does not always come from system planning and market research. But the real question now is how this success can be embraced by the vast IT industry. Oracle and several other big players are watching PHP. The facts show that the language is ripe.

Until now, success has only just "appeared". The growing number of enthusiasts have gathered around PHP as if they were gathered around a gifted prodigy. But since the child is growing a beard and is beginning to talk to adults on an equal footing, will early advocates adapt to this change?

Like most major open source projects, PHP is a fundamental phenomenon in the process of becoming a mainstream technology. Will PHP disappoint the people who have made it a reputation? Will it meet the expectations of a huge IT industry?

the story of two kinds of programming culture

The success of PHP has attracted the attention of people from different backgrounds. The advocates of the early Rasmus (if you can understand that some of the salvation-minded tones that are not often present in open source circles) are accustomed to quick, scripted scripting methods, they now have to deal with developers who understand UML, object-oriented (OO) programming, and those developers are determined to make PHP Keep abreast of other modern development tools. Both sides are well aware of WEB development and have a strong culture. It would be unwise to ignore either side.

Early PHP types understand what WEB development is all about, what is good at doing and what is not good at doing? It knows a lot about design problems. Its style may sometimes be problematic, but it can be seen that it has HTML and CSS features, not to mention the more popular multi-information Internet application (RIA) technology. It is always so young, but often appear in the PHP forum. The term "object-oriented" may have a negative implication for it. Its code is very concise, focusing on performance rather than on maintainability.

UML types will be less appealing because of the loosely-typed variables and the <?php?> statements that populate their HTML code. It will consider application architecture, class-level code reuse, team collaboration, and source code control. It knows that even moderately complex web sites are first and foremost an application, and poorly designed applications can cause delays, annoy customers, and even lose jobs.

At first glance, the latter seems to be more adapted to the increasingly demanding environment in which WEB development will increasingly be driven by marketing strategies and economic factors. But should we consider the former as an endangered species? Maybe it shouldn't be. If we admit that the Web is a very different medium from the desktop system-not to mention the mainframe (does anyone remember 3270?) , a dominant development approach in the mainframe environment--we might conclude that after all, we can learn something good and effective from this successful but relatively messy approach.

Let us review the practical issues so that they can be overcome before they occur and review some practical methods of work.

Bridging the cultural gap

Now PHP5 is about to bring object-oriented technology into the PHP world. Zend Engine Modification (ZE2) is introducing objects to the core of the language. Not only does the new language construct encourage object programming style, but also the implementation of language is adapting to other object-oriented environment. For example, objects are no longer copied back and forth by default, but are processed by reference. New keywords, such as final or static, are introduced, which are only relevant to the object concept, are reserved for Java style, and other attributes, such as delegates, encourage the use of object design patterns. (Expect to hear about "original PHP4" in a few months time.) This profound change comes from a relentless and revolutionary shift to the current dominant programming model. Whether you like it or not, object methods will be popular because they have proven themselves to be most effective in providing complex applications, whether they are Web applications or not. This leaves us with no choice but to look for imaginative ways to reconcile the two cultures so that those who have design ideas and those who understand the architecture can learn from each other.

To do this, various methods must be developed (or transformed from other platforms) to gain the versatility of the language while incorporating it within clear boundaries. In this way, the "island" of programming creativity can exist in a robust architecture.

One obvious fact is that, despite the explosive growth in the number of PHP CMS or application frameworks, there is no consensus on them. The recurring complaint is that no matter what your project is, the existing system will not be able to complete the task. Most people begin to evaluate a number of systems, and often end up developing their own frameworks from scratch. Why is that?

In the desktop system, it seems that the GUI design problem has been completely solved by the operating system, in contrast, the WEB is an important platform for original visual design. Web sites that host the image and personality of a business company can increasingly affect their revenue. Visual creativity and brand play a role together, and therefore must promote their development.

At the same time, you must be able to incorporate flexible logic into your application in order to improve the user experience as much as possible, keeping in mind that users are more likely to perform "dishes" on the Web than they would in a desktop system.

This is a problem when designers are constantly frustrated with the systems that programmers design, and this is also a problem when developers have to force application code into an incomplete portal framework. The most common outcome is an unsatisfactory compromise-some inflexible look, sacrificing a lot of usability to limit the complexity of the application to a manageable level. (This behavior is not limited to PHP applications.) ）

To overcome these limitations, designers and object-oriented developers must find a collaborative approach that does not hinder each other's work. The best approach may be to start by understanding how the opposing team works.

from skill to industry

Instead of thinking about collaboration at the moment, let's look at the actual operation. Let's start with the historical order of PHP by first accessing a store of "enhanced HTML" users.

The tools for trading are very similar to those of the "pure HTML" consumer: Some HTML editors, with various levels of comfort and project management features, and to some extent integrated with PHP, ASP, JavaScript, and less-than-minor tools.

Let's take some time to look at the code. The first thing we'll notice is that the Web sites generated with these different kinds of tools are pretty good. We're not just talking about technology, it's about talent. Freed from the constraints of abstract programming, WEB designers create a visual environment that makes your site's customers feel comfortable by fiddling with positive, subtle emotional effects (similar to the effects of smart decorators in real-world stores).

When we look at the code from the point of view of a trained object-oriented programmer, things suddenly get pretty bad. The code looks just like it itself: it is a one-time, forgotten job, without any preparation for future development or for easy maintenance. It is often so, indeed.

So, what's wrong with that? Will it become a problem later, leading to the abandonment of some or the entire Web site and rebuilding from the beginning? Maybe not. After all, real-store renovations are often dismantled and rebuilt regularly. As a result, cowboy-style PHP programming is sufficient for these window-like websites. The language is rich in a variety of skills that help achieve visual effects designed to attract visitors ' attention. This obviously has nothing to do with the object method.

This view changes dramatically once some application logic is needed. Do you need a number of forms to collect a small amount of marketing information about your site's regulars? If you want this information to be pertinent, it is a good idea to add a checksum code. If you do this, you should make sure that you can filter for malicious scripts or SQL instruction intrusive attacks. By the way, now that you are reading the OTN article, you must be familiar with the database (DB) problem. The information you are about to collect will be stored in some database tables, and the SELECT statement in your PHP code will reflect this database structure. From now on, this site is already anchored in your business infrastructure-it is becoming a full-fledged application.

Instead of all of its hard-coded links, dangerous type conversions, and security vulnerabilities, let's access the latest PHP object-oriented application assembly line. For our artist-style Web designers, such places may not be familiar or even unfriendly. It's not much of a skill here. WEB development has been industrialized. To be accepted here, you must be familiar with classes, inheritance, data abstraction, and a large number of code encapsulation tools.

Team collaboration requires rules. You must follow programming conventions; You must submit source files to version management and source control. Files are organized according to a rigorous modular hierarchy. Discard the dangerous coding techniques-especially those that are tricky to play with. Not only must the code be readable, but it must have good annotations.

This may be annoying, but it works. Now we are creating WEB applications: Intranets, commercial WEB sites, electronic markets, various applications, where flawed design can lead to closure. In short, we are overcoming complexity.

The manager of the PHP object-oriented assembly line did not choose PHP because they loved the language. They do this because it does not only work as effectively as other languages that are proprietary, but is free of charge and has no strings attached.

Where are we headed?

So how do we take advantage of the industry-level approach provided by people who have been trained in C + + and Java to complete the potential additions to the expertise of the versatile language used by early adopters?

PHP5 will shake a lot of habits, so this problem may be premature. Some people will be forced to adopt a certain level of object-oriented methods, while others will eventually understand all the content of the object and become its followers. Some small environments may run as well as they did in the past and continue to thrive.

let's try to practice

Now let's dive into the basic technical level, learn how to develop simple habits, and how to find simple and effective solutions that will help us prepare for the upcoming changes. A large number of very simple conventions help to facilitate programming and prepare the application for expansion.

Naming conventions (the habits of C + + programmers) are the easiest way to do it. If you've already used a lot of code libraries (for example, PEAR), it might be a good idea to use their conventions as your own, otherwise you should develop your own internal rules. Simplified Hungarian notation (named according to its Hungarian inventor Charles Symonyi) can be widely used in a range that is allowed by loose types. You can also use underscores as prefixes for class members. Another useful custom is to attach a special prefix (such as Impl_) to a method that is not used to invoke from outside the class (a function of a class).

Whatever naming convention you use, make your code as clear as possible. In this way, a trained person may find programming errors in Mansi PHP simply because it looks like a stain on the portrait.

Another important aspect of naming conventions is avoiding name collisions, making it possible to reuse code in large areas. Experience tells us that programmers are not always very imaginative in naming programming objects. It is quite possible that there are many page classes, and it is not impossible that when you reuse the two page classes you find that they are only of the same name and have different uses. That's not good luck. In the long run, renaming will bring maintenance problems. You'd better avoid this problem from the beginning. Generating GUIDs will be overkill and unsightly (for example, _16b280c5_ee70_11d1_9066_00c04fd9189d_page! And it runs counter to the spirit of PHP.

A simple and conflict-prevention approach is to ensure the uniqueness of the inner class by associating several different aspects of the class to its name (for example, Gallerypage), and then, in order to eliminate the various possibilities that conflict with classes outside of your control, you can press the Java The way you have the reserved version of the domain name as its prefix (com_mydomain_gallerypage).

Another habit to develop does not require you to spend anything, and when an application-wide unexpected change is unavoidable, it saves you work by encapsulating the most commonly used basic statements in a single channel. For example, in addition to debugging code, there should be only a "response" statement in the entire application, which should be in a function (or a separate class method). If you need to preprocess or redirect the output in a new environment, you know where to write the few lines of code you need without having to face the frustrating situation of searching and editing a large number of files.

Error handling does not have to be as strict as C + +-in C + +, a dangling pointer (dangling pointer) or a buffer overflow can be extremely damaging. When there is no compromise to data integrity, try to gently put down the shelf to tell the visitor, although some features are not perfect, but she can try again. A good helper that is often overlooked is the standard Set_error_handler () function. This is another example-this is the basic event-encapsulated in a centralized location where all the code is dedicated to dealing with these basic events. If you want to keep all the event logs that have errors in order to identify recurring problems, you should do this here.

Before we end low-level programming discussions, there is another life-saving technique. In PHP5, the object reference is assigned or passed by default (the reference is the handle of the object, not the object itself or a copy of the object). As long as we need to use PHP4, we must pay careful attention to the way objects are delivered. Some subtleties may make you uneasy. For example, the following statement causes $obj 20% to be a copy of $obj 1; that's not surprising.

$obj 2= $obj 1;

The function will use the copy and return the copy, unless otherwise specified-we have to accept the situation. The following example causes many errors that are difficult to track:

Class Objectkeeper {
var $_obj; Whatever object is
Function & Get_object () {
return $this->_obj;
}
}
References can be returned in good condition. Now the traps appear:
$keeper = new Objectkeeper ();
$obj 1 = $keeper->get_object ();
$obj 1->modify ();
$obj 2 = $keeper->get_object (); Ask new reference to same object
if ($obj 2->is_modified ()) {
Echo ' OK '; This will never print
}

The correct statement should be:

$obj 1=& $keeper->get_object ();//Note that "=&" rather than "="

If there is no =&amp, the copy of the object that the returned reference points to is assigned to $obj 1, and no matter what you do to the reference you think is correct, it does not affect the state of the original object. In other words, your updates will be lost.

Templates can be helpful in reconciling the cultural aspects of Web designers and programmers. They usually include everything in the layout (mostly HTML code), while the template engine fills in all the mutable content when the page is generated. Most template engines have a caching mechanism to ensure that the associated resource-intensive processing occurs only when data source updates require these processes.

the next step


Forum: PHP on Oracle

PHP Rover's Guide

Open Source Developer Center

Oracle + PHP Troubleshooting Guide

PHP Scripting: Arbitrary code is becoming popular

Getting started with Oracle + PHP

install Oracle, PHP, and Apache on Linux

The

Template engine allows for a considerable degree of distribution of layout and graphics at one end, with business logic at the other end. The most popular template engine may be Smarty, which is also exactly integrated into many open source CMS and framework projects.

Finally, it is important to note that the template engine tends to provide programming dialects when logic goes beyond the basic search-and-replace substitution. Future approaches are likely to rely on XSLT technology, and extended XML support in PHP5 will change a lot. The end of

is a fairly important aspect of practice: reusing Best-of-breed code from well-known libraries. Our research will be limited to PEAR because it is now part of a standard PHP release. The

PEAR may now be closer to a truly standard PHP software component. Strict selection of providers and stringent quality standards ensure that components are as good as commercial-grade components. Versioning practices provide you with precise control to determine which version of your component is appropriate for your application. Pear provides processing from the form to the database Abstraction layer (pear::D The!--emo&:D--> A wide range of features, including WEB services or WebDAV support, and other advanced features such as the!--endemo-->b.
Needless to say, by being familiar with PEAR and similar PHP code libraries, you can save a lot of days of intense research and development work.

PHP5

PHP has made itself one of the biggest open source success stories, with Linux and Apache abreast. Although not ideal, it has a firm foothold in the IT world, and its vast grassroots user base still likes it.

PHP5 may facilitate the development of heavily burdened Web applications, and the business logic layer interacting with the database is increasingly accepting PHP code. At the same time, flexible programming approaches will increasingly use XML technology, making it easier for WEB designers to collaborate without friction with developers and software designers.
We look forward to seeing a new generation of very attractive and very useful PHP based WEB applications.