Do you know PHP?

At the beginning of PHP, I started developing PHP about 10 years ago. It was a long time before the term "open source" appeared and GPL and free software were widely known. Just like many open-source projects that have become popular, motivation is by no means philosophical or even self-intoxicated. It is purely because a tool is needed to solve Web-related problems in reality. 1994

　　Early PHP

I started developing PHP about 10 years ago. It was a long time before the term "open source" appeared and GPL and free software were widely known. Just like many open-source projects that have become popular, motivation is by no means philosophical or even self-intoxicated. It is purely because a tool is needed to solve Web-related problems in reality. When talking about Web development tools in 1994, the selection was quite limited. I found that when I used C or Perl to write dynamic components for the Web site, Code overlaps between one problem and the other were significant. For the sake of performance, I am more and more away from Perl and tend to C, because the overhead of fork exec that must run Perl as a separate CGI is too restrictive.

The earliest unreleased version of PHP is mainly a C database for commonly used C functions. I have compiled these C functions so that they can be easily reused from one open source project to another open source project. I have a simple state machine-driven analyzer that picks out the mark from the HTML file and calls the backend C function I wrote. These codes were originally published as a package called Personal Home Page Tools, every tool in this package is an example of how to use the system to solve common problems with the personal homepage. In a later period, I separated some tools and called them FI, representing Form Interpreter ). The idea behind FI is that when you receive the results of a form submission, you need to do some common things and it can handle all these things. Some early examples:

Hey, you are using Netscape!

Sorry, that record does not exist

Welcome !

You have Credits left in your account.

My FI analyzer is very bad, which prompted me to try to write a better analyzer. I abandoned it. Instead Re-integrate some parts of the Personal Home Page Tools with this new FI tool, it was also released as a program named PHP/FI by the end of 1995 (this name imitates TCP/IP in a slightly joking way. PHP/FI has developed along with Web in the next few years. In February 1997, two Israeli users using PHP/FI, Zeev Suraski and Andi Gutmans, asked me if I was interested in using a new analysis engine. they will write this engine for the next version of PHP. I have gathered other people who have been providing patches and code for PHP/FI. we collaborated to release PHP 1998 in the middle of 3rd. This may be the most critical moment of PHP development. If this project has been working by one person, then it may have failed. if a group of strangers who have just joined together cannot figure out how to work towards a common goal, this project may also fail easily. In any case, we managed to solve our self-centered problems and other personal problems, and this project grew up. The number of people contributing to this project is growing steadily. now we plan to launch PHP 2004 at some time in the first half of 5.0.

　　The ugly duckling in programming language"

Popular views on PHP can be divided into two extremes. Language purification commentators often do not like many random feature implementations that are inconsistent with those that have emerged over the years. At the same time, the actual problem solver often prefers PHP to understand your intention and show that it is the ideal Web problem solving tool.

Some of the things that drive purifist's drive are: function names are case insensitive but variable names are case sensitive; built-in function names are inconsistent; PHP developers are not forced to use any real structure, this makes it easy to write messy code. In fact, I have to agree with these criticisms, but I can at least try to explain how and why we are in this situation.

First, the case-sensitive question about function names: this can be traced back to the earliest PHP version. In the early days of the Web (long before XHTML), it is common that all HTML tag tags are capitalized. However, because these labels are case-insensitive, they are not very consistent. I want people to treat PHP labels like other labels, which means PHP labels are case insensitive. When PHP becomes more advanced and has features such as variables, making these new features case-sensitive does not impair the backward compatibility of existing PHP pages. Looking back, when you suddenly process the original simple labels (these labels are actually just function calls), Case sensitivity will corrupt those pages and make them unavailable in the updated PHP version. In any case, people should not have functions with only different names in case. Even so, in retrospect, it was a good idea to break backward compatibility as early as possible when few people were using PHP, but at that time no one expected the amazing growth of PHP.

As for the function naming itself, I often learn some ideas from other languages and APIs that I am familiar. This means that PHP has functions such as strlen () and substr (). if they are written as str_len () or sub_str (), it looks a bit ridiculous. I have added functions such as stripslashes (), which are often written as StripSlashes () for length reasons to make it easier to understand. At the same time, I imitated the underlying database APIs, such as the msql_connect () function-miniSQL is the first database supported by PHP-they can be named using underscores. People familiar with these different sources will be very familiar with naming in PHP. When PHP acts as an interface between the Web server and all the different backend tools you want to hook on the Web server, it is not such an independent language. So today, when people see PHP as an independent language without considering its frontend and backend relationships, it may seem a bit different.

What I can say about the lack of a forced structure is that I absolutely hate programming frameworks that restrict me to a specific method to solve the problem. This does not mean that I do not trust the structure and framework, but I do believe that people can propose their own methods commensurate with their environment. Later in this article, I will discuss more about the possible architecture of various PHP projects.

All of this comes to the conclusion that PHP never intends to win any "beauty contest ". It does not aim to introduce any new revolutionary programming examples. It aims to solve a single problem: Web problems. This problem may be quite ugly, and sometimes you need an ugly tool to solve it. In fact, although a beautiful tool may solve the problem, it is often difficult to implement an ugly PHP solution faster and use less resources. This probably summarizes PHP's stubborn "superior functionality" approach over the years.

　　Suggestions for designers

The most popular deployment mode of PHP is to directly connect it to the pre-branch multi-process Apache 1.3.x Web server. Unlike Java, there is no independent process (such as JVM ). PHP is similar to scripting languages such as Perl and Python, in which scripts are directly analyzed and executed.

The absence of a central control process is a characteristic and also a cause of great setbacks for many people. PHP does not share any architecture-each of these requests is completely different and can be separated from any other request-making the language itself infinitely parallel scalable. PHP encourages you to put the scalability problem at the desired level. If you need shared data storage, you can use a database that supports replication and can be extended to the desired level. If you need a server load balancer request or assign a specific request to a specific server, you can use a front-end server load balancer that supports this function. By eliminating the central control process, PHP avoids being a bottleneck in the system. This makes PHP different from the judgment feature of tools that are commonly called application servers.

[Oarch1.png] a very common architecture for high-end PHP deployment

In, one or more load balancers distribute incoming requests to any number of Web servers. Considering data storage, you may deploy a read-only Database copy on each Web server (if the dataset is small enough, you can do that ), alternatively, you may create a separate database server tree to process various types of requests.

　　Add structure

One of the great advantages of PHP over many other tools for solving Web problems is that, other tools often link the solution to this very specific target problem with the requirement to control the user's solution to the problem from the structure. PHP does not force the use of any such structure. Instead, it chooses to focus on making the individual functional aspects of the problem as easy to use as possible. For example, PHP provides very purposeful functions to communicate with backend databases. These functions are dedicated to various databases and do not sacrifice any performance to obtain uniformity or consistency with other backend databases. In terms of file layout, there are no prescribed methods to build the structure of PHP applications.

The fact that PHP does not force the use of structures does not mean that you should not build PHP applications in an orderly and structured manner. When people ask me how I will start building a large PHP application structure, I like to show them the following method.

--------------------------------
| Html templates |
| $ DOC_ROOT/*. php |
--------------------------------
| Template helpers |
| $ DOC_ROOT/*. inc |
--------------------------------
| Business logic |
|/Usr/local/php/*. inc |
--------------------------------
| C/c core code |
|/Usr/local/lib/php/*. so |
--------------------------------

This solution solves some problems in four layers. First, it separates the content of a typical project along the responsibility clues. Web front-end developers work from the top layer, and backend engineers work from the bottom layer. They overlap in the template assistant layer. It also separates any HTML-containing files and places them into document_root, instead of any HTML-containing files outside document_root.

The top-layer template layer generally contains a very small number of PHP-only simple function calls and accidental inclusion. There may be a loop. These files are usually edited using an HTML editing tool. The second layer is the template assistant, which defines the interface between the business logic and the layout. This layer may have some convenient functions (such as start_table (), show_user_record () and any other reusable components, which make the work of the template maker easier.

The business logic layer does not contain any HTML at all. This is where SQL queries and any other PHP user space business logic are implemented. You can see that a function such as get_user_record () is implemented at this layer. This function will get an ID, execute the corresponding SQL query, and then return a Union array containing the result. Then, a function in the layer gets the array and wraps some HTML for it to make it look better.

The final C/C layer is the place where you place any customized back-end code required by a project. Many people have nothing on this layer, but if you have a dedicated C or C database, you can compile a PHP extension here to interface with the database. This layer is also used when a business logic function written in PHP is too slow.

　　Recruit and train PHP developers

PHP is not a new language. It does not introduce any new concepts. This means it is quite easy to train programmers who have knowledge of any language in C, C, Perl, or even Java to write PHP code. When I look for PHP developers to create a project, I tend to look for people with C or C skills, my idea is that it is much easier to recruit experienced programmers than to recruit people who must be familiar with PHP. If they can master these languages, PHP will be a piece of cake for them. Of course, it would be better if they had two experiences.

　　Freely deploy PHP

Use appropriate tools for work. I have met some companies that fully adopt PHP. they definitely deploy PHP everywhere, but PHP has never intended to become a common language suitable for all problems. It is mainly applicable to Web front-end scripting languages. Depending on the traffic of the Web site, it can also be used to perform a large number of backend work. However, in some cases, you may need to write part of your code in a strongly typed compilation language (such as C or C) to achieve optimal performance.

　　Where will PHP go?

People often ask me where PHP is going. This is a difficult question to answer, because PHP is mainly an open-source project that came into being. it is developed to meet the needs of its community. In PHP5, the integration of OO functions and XML has been greatly improved. We integrated an interesting tool called SQL-Lite, which directly provides an SQL interface for the file without the need for servers. Obviously, it cannot replace the actual database, but using it is undoubtedly a much better way than trying to write your own plain text file processing routine. The fact that it provides you with an SQL interface means it is easier to port to an actual database (if you need to do so at any time.

These changes in PHP5 are significant but progressive. We are not going to use this version to repeat the PHP world. In a script written for PHP4, you can work in PHP5 without modifying it. The biggest change is that the object processing in PHP5 is different. When you create an object in PHP5, a reference to the object is now obtained by default. you can pass it everywhere, you do not need to explicitly declare that you want to pass the object through reference as you must do in PHP4. In PHP5, if you want to obtain a copy of an object, you need to "clone" it.

In the long run, someone is studying the use of the Parrot engine. Parrot is written as the back-end engine of Perl6, but it is actually a general scripting engine unrelated to the language. If all the scripting languages can reach an agreement on a single backend engine, and the engine can be used as the basis for public extension and better language interaction, this will be very interesting.

In addition, some others are studying the Java connectivity of JSR 223, and think that Java can become a single universal backend of the scripting language.

Regardless of the future that PHP may have, one thing remains the same. We will continue to fight against the complexities that many people seem to be addicted. The most complex solution is rarely the right one. The specific and direct solution we provide to solve Web problems is what makes PHP stand out from the very beginning. when other solutions around us seem to become larger and more complex, we are trying to simplify and optimize PHP and its solutions to Web problems.