PHP has matured

Since PHP is maturing, it's time for quick, out-of-the-box scripters to "think on the same page" as UML-savvy object-oriented developers.
　　Few programming languages ​​have gained popularity as quickly as PHP. The now widely publicized story of do-it-yourself (DIY) scripting languages ​​transforming the IT industry shows that success doesn't always come from systematic planning and market research. But the real question now is how this success can be accepted by the vast IT industry. Oracle, as well as several other big players, are looking at PHP and the fact that the language has matured is evident.
Until now, success has just “appeared”. A growing number of enthusiasts have gathered around PHP like a prodigy. But now that the kid is growing a beard and starting to talk to adults on an equal footing, will the early advocates adapt to the change?
　PHP, like most major open source projects, is a fundamental phenomenon in the process of becoming a mainstream technology. Will PHP fail the people who gave it its reputation? Will it live up to the expectations of the massive IT industry?
A story of two programming cultures
　The success of PHP has attracted the attention of people from different backgrounds. The early Rasmus proponents (if you'll pardon the slightly messianic tone not often found in open source circles) were accustomed to fast, out-of-the-box scripting methods, and they now had to contend with those who understood UML. , object-oriented (OO) programming developers who are determined to keep PHP on par with other modern development tools. Both parties know web development well and have a strong culture. It would be unwise to ignore either side.
　What did the early PHP types know about web development, what was it good at, and what was it bad at? It knows a lot about design. Its style can be questionable at times, but you can tell it has HTML and CSS capabilities, not to mention the more popular Rich Internet Application (RIA) technology. It's always young, but appears frequently in PHP forums. The term "object-oriented" may have negative connotations about it. Its code is concise and focuses on performance rather than maintainability.
UML types will be less attractive due to loosely typed variables and filling their HTML code with statements. It will consider application architecture, class-level code reuse, teamwork, and source code management. It knows that even a moderately complex website is first and foremost an application, and that a poorly designed application can lead to delays, annoyed clients, and even lost jobs.
　At first glance, the latter seems more suitable for an increasingly demanding environment, where web development will be increasingly driven by marketing strategies and economic factors. But should we consider the former an endangered species? Maybe it shouldn't be this way. If we accept that the Web is a very different medium than desktop systems—not to mention mainframes (anyone remember the 3270?), which gave rise to the dominant development methodology in mainframe environments—then we might Conclusion, after all, there are good and effective things to be learned from this successful but relatively messy approach.
　Let’s review actual problems to overcome before they happen, and review some practical ways of working.
Bridging the cultural gap
Now PHP5 is about to bring object-oriented technology into the PHP world. Zend engine modifications (ZE2) are bringing objects into the core of the language. Not only are new language constructs encouraging an object programming style, but language implementations are also being adapted to other object-oriented environments. For example, instead of copying objects back and forth by default, they are handled by reference. New keywords (such as final or static) are introduced, which are related only to the object concept and are a preservation of Java style; other features (such as delegation) encourage the use of object design patterns. (Expect to hear everyone talking about "Original PHP4" in a few months' time.) This profound change comes from a ruthlessly revolutionary shift toward the currently dominant programming model. Like it or not, the object approach is here to stay because it has proven itself to be the most effective at delivering complex applications, whether they are Web applications or not. This leaves us with no choice but to find imaginative ways to reconcile the two cultures so that people who think about design and those who understand architecture can complement each other.
To do this, methods must be developed (or translated from other platforms) to gain the versatility of the language while containing it within clear boundaries. In this way, "islands" of programming creativity can exist within 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. A common complaint that comes up is that no matter what your project is, your existing system just doesn't get the job done. People often start by evaluating several systems and often end up developing their own framework from scratch. why is that?
　In desktop systems, GUI design issues seem to have been completely solved by the operating system. In contrast, the Web is a platform where original visual design plays an important role. Web sites carry a business company's image and personality, which may increasingly affect its revenue. Visual creativity works hand-in-hand with branding, so they must be promoted.
　At the same time, you must be able to weave flexible logic into your application in order to improve the user experience as much as possible, keeping in mind that users are more sophisticated on the web than they may be on a desktop system.
　It’s a problem when designers are constantly frustrated by the systems programmers designed, and it’s equally a problem when developers have to shoehorn application code into an incomplete portal framework. The most common outcome is an unsatisfactory compromise - a somewhat dull look, sacrificing a lot of usability in order to limit the complexity of the application to a manageable level. (This phenomenon is not limited to PHP applications.)
To fully overcome these limitations, designers and object-oriented developers must find a way to collaborate without hindering each other's work. The best approach may be to start by understanding how the other team works.
From technology to industry
　 Don’t think about collaboration issues at this moment, let us observe their actual operations. Let's start in PHP's historical order, first by visiting an "enhanced html" user's store.
　The tools for trading are very similar to those for "pure html" users: a few html editors with various levels of comfort features and project management features, and to some extent PHP, ASP, JavaScript and lesser tools integrated.
　Let’s take a moment and take a closer look at the code. The first thing we will notice is that the websites produced using these different kinds of tools are very beautiful. We’re not just talking about skill here, but also talent. Freed from the constraints of abstract programming considerations, web designers create a visual environment that puts your website's customers at ease by playing with positive, subtle emotional effects—similar to those created by an astute decorator in a real store.
　When we look at this code from the perspective of a trained object-oriented programmer, things suddenly go very wrong. The code looks like what it is: a one-time, forget-it-it job that makes no provision for future development or easy maintenance. Often, indeed.
　So, what’s wrong with this? Will it become a problem later, leading to abandoning part or the entire site and rebuilding it from scratch? Maybe not. After all, real store decorations are often torn down and rebuilt on a regular basis. So, for these showcase websites, cowboy-style PHP programming is sufficient. This language is rich in techniques that help achieve visual effects designed to attract the attention of your visitors. This obviously has nothing to do with object methods.
　This view changes significantly once some application logic is required. Do you need several forms to collect small amounts of marketing information about your site's frequent visitors? If you want this information to be relevant, it's a good idea to add a verification code. If you do this, you should ensure that you can filter intrusive attacks with malicious scripts or SQL instructions. By the way, since you are reading an OTN article, you must be familiar with database (DB) issues. The information you will collect will be stored in some database table, and the SELECT statements in your PHP code will reflect this database structure. From now on, this website is already fixed in your business infrastructure - it is becoming a full-fledged application.
Let’s put aside all the hard-coded links, dangerous type conversions, and security holes for now and visit the latest assembly line of PHP object-oriented applications. For those of us artist-minded web designers out there, this kind of place may be unfamiliar and perhaps even unfriendly. Not much emphasis is placed on technique here. Web development has become industrialized. To be accepted here, you must be familiar with classes, inheritance, data abstraction, and a host of code encapsulation tools.
　Team collaboration requires rules. Programming conventions must be followed; source files must be submitted to version control and source code control. Files are organized according to a strict modular hierarchy. Dangerous coding techniques—especially clever ones—are eliminated. Not only must the code be readable, but it must also be well commented.
　This may be annoying, but it works. Now we are creating Web applications: intranets, business Web sites, electronic marketplaces, applications of all kinds where a flawed design can put a stop to business. In short, we are overcoming complexity.
　PHP Object-oriented assembly line managers didn’t choose PHP because they loved the language. They do this because not only does it get the job done just as effectively as those other proprietary languages, but it's also free and comes with no strings attached.
Where are we going?
So how do we leverage industry-grade methods provided by those trained in C++ and Java to potentially complement the expertise of early adopters of versatile languages?
　PHP5 will shake a lot of habits, so this question may be premature. Some people will be forced to adopt a certain degree of object-oriented approach, while others will eventually learn all about object-oriented and become believers in it. Certain niches may function just as well as they did in the past and continue to thrive.
Let’s practice it
Now let’s dive into the basic technical level to understand how to create simple habits and how finding simple yet effective solutions will help us prepare for the changes that are coming. A number of very simple conventions help facilitate programming and make the application ready for expansion.
　 Naming conventions (the habits of C++ programmers) are the easiest way. If you already use a code base (such as PEAR) heavily, it might be a good idea to adopt its conventions as your own; otherwise you should develop your own internal rules. Simplified Hungarian annotation (named after its Hungarian inventor, Charles Symonyi) can be used as widely as the loose type allows. You can also use an underscore to prefix class members. Another useful habit is to append a special prefix (such as impl_) to methods (functions belonging to a class) that are not intended to be called from outside the class.
　No matter what naming convention you adopt, make your code as unambiguous as possible. Thus, a trained person might find a programming error in a screen full of PHP just because it looks wrong, like a stain on a portrait.
Another important aspect of naming conventions is to avoid name conflicts, making it possible to reuse code on a large scale. Experience tells us that programmers are not always very imaginative in naming programming objects. Chances are, there are many Page classes out there, and it's not impossible that you might want to reuse two Page classes only to find that they have the same name but completely different purposes. Really unlucky. In the long run, renaming will cause maintenance problems. You're better off avoiding this problem in the first place. Generating a GUID would be overkill, ugly (e.g. _16B280C5_EE70_11D1_9066_00C04FD9189D_Page!) and goes against the spirit of PHP.
A simple way to prevent conflicts is to ensure the uniqueness of the inner class by associating several different aspects of the class into its name (e.g. GalleryPage); then, to eliminate conflicts with classes outside of your control Possibility of conflict, you can prefix it the Java way with a reserved version of the domain name you own (com_mydomain_GalleryPage).
Another habit to develop that costs you nothing and can save you work when unexpected changes to a certain application scope are unavoidable is to encapsulate the most commonly used basic statements in a separate channel . For example, other than debugging code, there should only be one "response" statement in the entire application, and it should be in some function (or separate class method). If a new environment requires preprocessing or redirecting output, you know where to put the required few lines of code without having to face the frustrating situation of searching and editing a large file.
　Error handling doesn’t have to be as strict as in C++ — a dangling pointer or buffer overflow can be very destructive in C++. When data integrity is not compromised, try to be generous and tell the visitor that although some functions are not perfect, she can try again. An often overlooked helper is the standard set_error_handler() function. This is another example of - this time basic events - being encapsulated into a centralized location where all code is dedicated to handling these basic events. If you wish to keep an event log of all errors that occur so you can identify recurring problems, this is where you should do it.
Before we end our discussion of low-level programming, here’s another life-saving trick. In PHP5, by default, an object reference is assigned or passed (a reference is a handle to an 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 how objects are passed around. There are some subtleties that may unsettle you. For example, the following statement causes $obj2 to become a copy of $obj1; this is not surprising.
$obj2=$obj1;
　 The function will use the copy and return the copy unless otherwise specified - we have to accept this situation. The following example leads to a lot of hard-to-track errors:
class ObjectKeeper {
var $_obj; // Whatever object is
function & get_object() {
_ return $this->_obj;
}
}
//References can Returned in good condition. Now the trap appears:
$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 should be:
$obj1= &$keeper->get_object(); // Note that it is “=" What you do with the reference that you think is correct will not affect the state of the original object. In other words, your updates will be lost.
　Templates can go a long way in harmonizing the culture of web designers and programmers. They usually include everything that goes into the layout (mainly HTML code), with the template engine filling in all the variable content when generating the page. Most template engines include caching mechanisms to ensure that resource-intensive processing occurs only when updates to the data source require it.
Next Steps
Forum: PHP on Oracle
PHP Hitchhiker's Guide
Open Source Developer Center
Oracle + PHP Troubleshooting Guide
PHP Scripting: Freewheeling Code Gains Popularity
Getting Started with Oracle + PHP
Installing Oracle, PHP and Apache on Linux

　The template engine allows to a considerable extent to separate layout and graphics on one end and business logic on the other. The most popular template engine is probably Smarty, which also happens to be integrated into many open source CMS and framework projects.
Finally, it’s important to note that template engines tend to provide programming dialects when the logic goes beyond basic search-and-replace. Future approaches are likely to rely on XSLT technology, and extended XML support in PHP5 will change a lot as a result.
　Finally, a very important practical aspect: reusing first-class code from well-known libraries. Our research will be limited to PEAR as it is now part of the standard PHP distribution.
　PEAR may currently be closer to a truly standard PHP software component. Rigorous provider selection and stringent quality standards ensure components are as good as commercial grade components. Versioning conventions give you precise control over which version of a component is appropriate for your application. PEAR provides a rich set of capabilities from form processing to a database abstraction layer (PEAR::DB), and includes advanced features such as web services or WebDAV support.
　Needless to say, you can save many days of intense R&D work by becoming familiar with PEAR and similar PHP code libraries.
PHP5 is coming
　 PHP has established itself as one of the biggest open source success stories, alongside Linux and Apache. Despite its shortcomings, it has firmly established itself in the IT world and its large base of users still loves it.
　PHP5 may facilitate the development of heavy-duty web applications, with the business logic layer that interacts with the database increasingly accepting PHP code. At the same time, flexible programming methods will increasingly use XML technology, making it easier for web designers to collaborate frictionlessly with developers and software designers.
　 We look forward to seeing a new generation of very attractive and easy-to-use PHP-based web applications.

The above has introduced that PHP has matured, including the content of economics. I hope it will be helpful to friends who are interested in PHP tutorials.