Web Client Programming

The web's original server-browser solution provides interactive content, but this interaction capability is entirely provided by the server, bringing a burden on the server and the Internet. Servers typically generate static Web pages for client browsers, which are simply interpreted and displayed. The basic HTML language provides a simple data-gathering mechanism: Text-entry boxes, checkboxes, radio buttons, lists, and Drop-down lists, and a button that can only be reset by the program's data in the form to be passed back to the server. The information submitted by the user is uploaded to the server through a "Common Gateway Interface" (CGI) that all Web servers can support. The text contained in the submit data indicates how the CGI should operate. The most common action is to run a program that is located on the server. The program is generally stored in a directory named "Cgi-bin" (When you press a button in a Web page, notice the Address window at the top of the browser and often find the word "cgi-bin"). Most languages can be used to compile these programs, but Perl is the most common. This is because Perl is designed for text processing and interpretation, so it can be installed and used on any server, regardless of the processor or operating system used.

Note: This section is adapted from an article by an author. The article first appeared on the mainspring in www.mainspring.com. The use of this section has been approved by the other party.

Many web sites today are strictly based on CGI, and virtually everything can be done with CGI. The only problem is response time. The response of a CGI program depends on how much data needs to be delivered, and how heavily the server and the Internet are burdened (and the CGI program starts slowly). The early web designers did not anticipate that more than enough bandwidth had quickly become scarce, which was the result of a flood of applications flooding the Web. For example, any form of dynamic graphical display can be displayed almost coherently because at this point you must create a GIF file and then pass each of the graphics changes from the server to the customer. And you should have a deep understanding of the data validation on the input form. The original method is that we press the submit button on the page (submit); The data is passed back to the server; The server starts a CGI program to check the user's input for errors; Formats an HTML page, notifies you of possible mistakes, and passes the page back to us; then you have to go back to the original form page, Enter it again. This method is not only very slow, but also very cumbersome.
The solution is the client program. Most machines that run Web browsers are strong enough to do a lot of other work. At the same time, the original static HTML method can still be used, and it will wait until the server is sent back to the next page. Client-side programming means that Web browsers can be more fully leveraged and can effectively improve the interactive (interactive) capabilities of the Web server. The
discussion of client-side programming is not much different from the discussion of general programming issues. The parameters used are certainly the same, but the platform is different: a Web browser is like a limited operating system. Anyway, we still need programming, we still have a lot of problems in client programming, and there are a lot of solutions. In the remainder of this section, we will summarize these issues and explain the countermeasures taken in client programming.

1. Plugin
toward client programming, the most important issue is the design of plug-ins. With Plug-ins, programmers can easily add new features to browsers, and users simply download some code and "insert" them into the appropriate location in the browser. The purpose of this code is to tell the browser that "from now on, you can do these new activities" (just download these inserts once). Some quick and powerful behaviors are added to the browser through Plug-ins. But the writing of Plug-ins is not a simple task. When we build a particular site, we may not want to be involved in this effort. For client programming, the value of plug-ins is that it allows professional programmers to design a new language and add that language to the browser without having to go through the browser creator's permission. As you can see, plug-ins are actually a "backdoor" of browsers, allowing you to create new client programming languages (although not all languages are implemented as Plug-ins).

2. Scripting language
Plug-ins contribute to the explosive growth of scripting languages. In this scripting language, the source code for your own client program can be inserted directly into the HTML page, and plug-ins that interpret that language are automatically activated when the HTML page is displayed. Scripting languages tend to be as simple as possible and easy to understand. And because they are a simple body of text that belongs to an HTML page, you can load it very quickly by simply sending a request to the server for that page. The downside is that our code is all exposed to people. On the other hand, this problem can be put aside for a while because it's usually not done in a scripting language.
The scripting language is really geared toward solving a particular type of problem, which involves creating a richer, more interactive graphical user interface (GUI). However, the scripting language may solve 80% of the problems in client programming. The problem you're in is probably exactly 80%. And since scripting languages are designed to be as simple and fast as possible, before considering other, more complex scenarios (such as Java and ActiveX), you should first think about the feasibility of scripting languages.
The scripting languages that are most discussed today include JavaScript (which has nothing to do with Java; it's called a marketing strategy), VBScript (very similar to Visual Basic), and tcl/ Tk (derived from the popular Cross-platform GUI construction language). Of course there are many other languages, and many are under development.
JavaScript may be common, and it gets the most comprehensive support. Both Netscapenavigator,microsoft Internet Explorer and Opera are currently providing support for JavaScript. In addition, there are more books on the market for JavaScript than other languages. Some tools can also use JavaScript to automatically generate Web pages. Of course, if you already have the deep foundation of Visual Basic or TCL/TK, it's much simpler to use them, at least to avoid the trouble of learning a new language (web-related problems are already a headache).

3. Java
If a scripting language solves 80% of client programming problems, what about the remaining 20%? Do they belong to some highly difficult problems? The most popular option at the moment is java. It is not only a powerful, highly secure, cross-platform use and universal programming language, but also a strong vitality of the language. The expansion of Java is ongoing, providing the language features and libraries can be a good solution to the traditional language can not solve problems, such as multithreading, database access, network programming and distributed computing and so on. Java solves the problem of client programming skillfully through "program Slice" (applet).
A piece of program (or "small application") is a very small program that can only be run in a Web browser. As part of a Web page, the program code is automatically downloaded back (this is similar to the picture in the Web page). After the patch is activated, it executes a program. One of the advantages of the program is that the software can be downloaded automatically from the server once the user needs the client software. They can automatically get the latest version of the client software, without errors, and without the hassle of reinstalling. Because of the Java design principle, programmers only need to create a version of the program that can run on almost any computer and in a browser that has a Java interpreter installed. Since Java is a full-featured programming language, we can do as much work on the client as possible before making a request to the server. For example, you no longer have to send a request form over the Internet, and the server determines whether there is a spelling or other parameter error. Most data validation work can be done on the client, and there is no need to sit in front of the computer and wait for the server to respond anxiously. In this way, not only the sensitivity of speed and response has been greatly improved, the burden on the network and servers can also be significantly reduced, which is essential to ensure the smooth flow of the Internet.
Another advantage of Java programs, compared to scripting, is that it takes a compiled form, so the client doesn't see the source code. On the other hand, it is not difficult to decompile Java patches, and the hidden code is generally not an important issue. We should pay attention to two other important issues. As this book would have mentioned before, a compiled Java patch might contain a lot of modules, so you have to "hit" (access) the server multiple times to download (in Java 1.1, this problem has been effectively improved-using Java compressed file, or jar files – It allows the designer to encapsulate all the necessary modules together for users to download uniformly. On the other hand, the script is integrated into a Web page as part of the body of the Web page. This program is generally very small, can effectively reduce the number of clicks on the server. Another factor is the learning side of the problem. No matter what you usually hear, Java is not a very easy language to learn. If you used to be a Visual Basic programmer, switching to VBScript would be the quickest solution. Since VBScript solves most of the typical client/server problems, it is hard to make up your mind to learn Java once you get started. If you are familiar with scripting languages, it is advisable to familiarize yourself with JavaScript or VBScript before turning to Java, as they may already be able to meet your needs without having to go through the hard process of learning Java.

4. ActiveX
To some extent, a strong competitor of Java should be Microsoft's ActiveX, although it uses a completely different set of implementations. ActiveX is originally a pure windows solution. With the efforts of an independent professional association, ActiveX now has the ability to use Cross-platform. In fact, ActiveX means "If your program is connected to its working environment, it will be able to go into the Web page and run in an ActiveX-enabled browser" (ie solidified the support for ActiveX, and Netscape needs a plugin). So, ActiveX does not limit our use of a particular language. For example, suppose we are already an experienced Windows programmer who can skillfully use a language like C + +, Visual Basic, or Borlanddelphi to create ActiveX components almost without any learning. In fact, ActiveX is the best way to use "legacy" code in our web pages.

5. Security
Automatically downloading and running programs over the Internet sounds like a virus maker's dream. In client programming, ActiveX poses the most vexing security issue. When you click on a Web site, you may return any number of things along with HTML pages: GIF files, scripting code, compiled Java code, and ActiveX components. Some are harmless; GIF files do no harm to us, and scripting languages usually have a lot of limitations on what they can do. Java is also designed to run in a secure "sandbox" in its patches, which prevents operations from being located in a disk or memory area other than the sandbox.
ActiveX is one of the most worrying of all of these. Using ActiveX programming is like writing a Windows application--you can do whatever you want. After downloading back to an ActiveX component, it is completely likely to cause damage to the files on our disks. Of course, for those programs that are downloaded back not limited to running inside a Web browser, they can also disrupt our system. Viruses downloaded from BBS have been a big problem, but the speed of the Internet has made the problem more complicated.
The solution is "digital signature", the code will be validated by the authority, showing the author who it is. This mechanism is based on the belief that the virus spreads because its creator is anonymous. So if the anonymity factor is removed, all designers will have to take responsibility for their actions. This seems to be a good idea because it makes the program look more formal. But I am skeptical that it can eliminate the malicious elements, because if a program contains bugs, it can also cause problems.
Java uses "sandbox" to prevent these problems from occurring. The Java interpreter is embedded in our local Web browser, and all suspected instructions are checked when the patch is loaded. In particular, the program does not have the right to write files to disk or to delete files (this is one of the things that viruses like to do most). We usually think of the program as a safe piece. And because security is critical to building a reliable client/server system, all bugs that leave bugs behind can be quickly repaired (the browser software actually has to enforce these security rules; and some browsers allow us to choose different levels of security to prevent varying degrees of access to the system).
You may wonder if this restriction will prevent us from writing files to the local disk. For example, we sometimes need to build a local database, or save the data for later use offline. The earliest version seems to be that everyone can do anything sensitive online, but it quickly becomes very unrealistic (although low-cost "Internet Tools" may one day meet the needs of most users). The solution is "signed program", which verifies that the program is actually from the place it claims to be, using a public key encryption algorithm. Of course, after verification, a signed piece of the program can still start to erase your disk. But in theory, since it is now possible to find the founders "accounts", they generally do not do such a stupid thing. Java 1.1 provides a framework for digital signatures and, when necessary, allows a piece of the program to "walk" outside the sandbox.
The digital signature omits an important question, which is the speed at which people move on the internet. If you download a bug-riddled program and it unfortunately does some stupid thing, how long does it take to find out? This may be a few days, or maybe a few weeks later. After discovering, how to track the process of the original accident (and how much responsibility it was at that time)?

6. Internet and Intranet
The web is a common solution for client/server issues, so it's a good idea to use the same technology to address some "subsets" of such problems, especially traditional client/server issues within the company. The problem with the traditional client/server model is that there are many different types of client computers and it is difficult to install new client software. However, both types of problems can be solved well through web browsers and client programming. If an information network is limited to a particular company, then after applying web technology to it, you can call it an intranet, which is different from the international Internet. The intranet provides a greater level of security than the Internet because it can physically control the use of internal servers within the company. When it comes to training, generally as long as people understand the general concept of the browser, you can easily grasp the differences between the Web page and the program, so the cost of learning a new system will be significantly reduced.
Security issues introduce us to the domain of client programming, a branch that seems to be automatically formed. If the program is running on the internet, because there is no way to know what platform it will run on, so program to pay special attention to prevent possible programming errors. There is a need for cross-platform processing, as well as appropriate security precautions, such as the use of a scripting language or Java.
But if you run in the intranet, some of the constraints you face will change. All machines are intel/windows platform is a very common thing. In the intranet, you need to be responsible for the quality of your own code. And once you find the error, you can correct it right away. In addition, there may already be some "legacy" code that uses the more traditional client/server approach. But in the upgrade, each time you have to rationally install a client program. Wasting time on an upgrade installation is an important reason to move to a browser. With the browser, the upgrade becomes easy, and the entire process is transparent and automated. If it is true that an intranet is involved, the most sensible approach is to use ActiveX rather than trying to rewrite the code in a new language.
When faced with a bewildering range of solutions to client programming problems, the best solution is to do an investment/return analysis first. Please sum up all the constraints on the problem and what is the quickest solution. Since client programming still has to be programmed, the best way to develop your own particular situation is in any case. This is the best posture we can make when preparing for some unavoidable problems in program development.