PHP Learning Guide-Chapter 2

Server-side Web Scripting language

Key points of this chapter
·Understanding static and dynamic Web pages
·Comparison of client-side and server-side Scripting languages
·Introduction to server-side Scripting language

This chapter focuses on discussing the server-side Scripting language itself. In addition It also talks about its relationship to static HTML and client-side technologies in general. By the end of this chapter, readers will have a clear idea of ​​what PHP can and cannot do, as well as a general understanding of how it originally communicates with the client.

Static HTML

The most basic form of Web pages is a purely static, text-only page written entirely in HTML. The simple HTML page in Figure 2-1 is an example.

Server-side Web Scripting language

Focus of this chapter
·Understanding static and dynamic Web pages
·Comparison of client-side and server-side Scripting languages
·Introduction to server-side Scripting language

The focus of this chapter is to discuss the server-side Scripting language itself. It also talks about its relationship to static HTML and general client-side technologies. By the end of this chapter, readers will have a clear idea of ​​what PHP can and cannot do, as well as a general understanding of how it originally communicates with the client.

Static HTML

The most basic form of Web pages is a purely static, text-only page written entirely in HTML. The simple HTML page in Figure 2-1 is an example.

Figure 2-1 Static HTML web page specification

The following is the source code of Figure 2-1:

As shown in Figure 2-2, when the client computer makes a response from the server through the Web or Intrantet When making an HTTP request for a page, the server only needs to pass the plain text that cannot be found in the archive.

When the data is sent back to the client computer, the browser makes the best possible processing and presentation based on its precise analysis of the source code content, user preferences, monitor size, and other factors. The content of the HTML file on the server is exactly the same as the source code of the page on the client computer.

Very ordinary static HTML like yours has the following advantages:

◆ Any browser has the ability to display it.

◆Most devices have the ability to display it.

◆It executes every request quickly and uses minimal resources.

◆ HTML is easy to learn or automatically generated.

◆ Quickly make small changes to individual pages.

◆ Of course, static HTML also has a downside:

◆ It’s difficult to control the design and layout.

◆ Cannot scale to a large number of pages.

◆ The interactivity is not good enough.

◆ Easily contain meaningful metadata about the page.

◆ It is not easy to cope with rapid changes in content or personalized information.

◆ Not very attractive.

Because... it can only be regarded as an "amateur" level or a certain ideal application (this ideal is as firm as a web page written by some computer science experts, and they believe that all web pages should comply with the HTML3.1 specification and must be installed on all devices can be read).

In response to these limitations, many other technologies have been developed recently, including client-side JavaScript, Cascading Style Sheet (CSS) and Java applets, as well as server-side scripting languages ​​for server-side database connection. Technologies under development include XML and XSL, both of which are part of various other specifications (XHTML, XSLT, XPath, ICE, etc.).

If you take some time to understand what functions these technologies have and whether they can be added to your own Web site, you will definitely reduce the chance of causing you headaches in the future. For any web task at hand, the first basic question to ask yourself is: Where is this computation performed, the client or the server?

The meaning of "dynamic" There is a basic and recurring difference between "static" and "dynamic" web pages, but "dynamic" can mean almost everything except ordinary HTML. It is used to describe both client-side functionality and server-side functionality. On the user side, "dynamics" can be seen as multimedia displays, scrolling title rows, automatically updating pages, or elements that appear and disappear... etc. On the server side, the term is generally used to refer to content being transmitted over the air and interactively assembled.

Client technology

For ordinary HTML, the most common content addition occurs on the client side. This includes the following: format extensions like CSS and Dynamic HTML, client-side scripting languages, Java applets, and Flash. Support for these technologies is (mostly supported) built into Web browsing. Table 2-1 lists their functions, some of which overlap.

Table 2-1 Client-side HTML extensions

The page example listed in Figure 2-3 is based on the same content as Figure 2-1.

As you can see from the source code, this example adds some new style sheets, client-side scripting and some more complex HTML code.

Unfortunately, the best selling point of client-side technologies is also their worst quality: they are completely dependent on the browser. The functions of each browser vary greatly, even among different versions produced by the same brand. Everyone can also choose to configure their browsers in different ways. For example, some people may disable the use of JavaScript due to security concerns, making it impossible for them to browse sites that excessively use JavaScript for navigation. (If we show the function in the previous example)

Moreover, many users have poor results in browser upgrades due to cost or lack of technology. Web developers should have an understanding of device-based browsing, general and global users, and more. Without exception, websites designed for the mass market try to reach the widest possible audience. For example, Yahoo! and Amazon have insisted on not using style sheets and JavaScript for more than three years after adopting these standards. Under pressure from the W3C, many websites still stubbornly insist on using the FONT tag and BGCOLOR attributes. Their customers may be users who are using AOL 3.0 on older Macintosh machines with 13 o'clock monitors. What's even more ironic is that even after the Web has experienced five years of rapid development, the only thing developers can absolutely guarantee to customers is that they will see ordinary HTML, which is mainly plain text. (Or even a subset of HTML that has successfully and easily stood the test of time)

Finally, client-side technology cannot do any work that requires connecting to a backend server. JavaScript cannot instantly generate a customized drop-down list based on user preference options stored in the database. When changes need to be made in the list, web developers must go to the page to make manual changes (server-side JavaScript, but it is not currently used. Too many) For this problem, server-side JavaScript language is the savior that can bridge this gap.

In short, all actions that handle layout configuration or browser events occur on the user side. Generally speaking, cool-looking effects or things that depend on mouse movement are done on the user side. You can see that the faster an event appears, the more likely it is that it is handled by the client, because faster speeds mean there is no need to download from the server.

Note:
Java applets, also known as "client-side Java (client-side Java)", are less dependent on the browser than other client-side technologies. As the name implies, they are complete small Java applications delivered over the Internet. However, unlike applications written in other programming languages ​​that interact directly with the client's operating system, Java applets execute on a software called the JVM (Java Virtual Machine). Virtual Machine, Java virtual host) intermediary software. JVM can be regarded as an operating system that exists on top of a real operating system. Most of the latest browsers will have a JVM that is not enough. Of course, you can also download one separately for use. This distinction in work allows the applet to allow the browser to perform special functions without being restricted by the browser's relatively weak capabilities.

Applets were considered to be meaningless little things in the early days, because they were originally used to implement some simple animations, such as icon logos that looked like transparent glue, scrolling title bars, jumping keys, etc. . Fortunately, applets have evolved and can be used for some very humanistic purposes, such as crossword puzzles, Tower of Hanoi simulations, trying on suits and accessories, and virtual modes.

Server-side scripting language

Figure 2-4 is a schematic diagram of the server scripting data process.

Client-side scripting language is very attractive and is the most eye-catching part of web development. Server-side programming is just the opposite. It is invisible to the user and hidden behind it. Server-side scripting programmers are always trying to explore the data on the back-end Web server, while colleagues with artistic talents on the front-end can express their works in front of the public.

The scripting language of the server-side Web is mainly to connect the Web website to the back-end server, such as a database, which allows two-way communication:

The scripting language of the server-side Web is mainly to connect the Web website to Back-end servers, such as databases, allow for two-way communication:

◆ Server to client: Web pages can be combined from the output of the back-end server.

◆ Client to server: Make the information input by the client effective.

Common examples of user-to-server communication are online forms and some drop-down lists that are dynamically combined on the server. (Usually it requires you to press a button).

Server-side scripting language products have two main parts: scripting language and scripting engine (which may or may not be built into the web server). The engine parts are all developed by the same company or team and can only be used in conjunction with each other (PHP3 and ColdFusion are two such examples). However, there are exceptions to this rule. For example, Java Server Pages are written in standard programming languages ​​rather than special-purpose scripting languages; some partners have developed several compatible and interchangeable engines (such as Allaire JRun, Apache JServ).

Theoretically, Active Server Pagesb allows the use of most scripting languages ​​​​and one of several matching ActiveX scripting engines (however, in practice, except for the combination of NT/IIS/VBScript/JScirpt , there are many problems with other combinations). Since PHP4's scriptingz engine (Zend) is currently theoretically separated from the PHP programming language, PHP4 is now considered a separate and independent scripting technology.

Figure 2.5 lists an example of a simple server-side scripting language. Based on the server-side source code and the client-side source code, a page is generated instantly from the database. We've included the database calls (which we won't go into detail until Part II of this book) and omitted some of the included files because the purpose of this example is to show the final product of PHP, not to be a formal Job executable source code usage

The following is the source code on the server

This is the source code presentation form of the same page when it reaches the client:

The above is the content of the PHP Learning Guide - Chapter 2, more For related content, please pay attention to the PHP Chinese website (m.sbmmt.com)!