• Choose a category
• All
• Classic-Fiction

Programming on the server

Server-side programming is what you use to create pages dynamically on the server before sending them to the client. Whereas client-side programming is executed on the client’s machine, server-side programming all happens on the server before the Web page is even sent to the user.

Client-side programming (as done in JavaScript) does most of the work on the individual user’s machine. This has advantages because those machines have doohickeys, like mice and graphics cards. Client-side programs can be interactive in real time.

The client has a big problem, though. Programs written on the client usually have a form of forced amnesia (no long-term memory). For security reasons, client-side applications can’t store information in files and can’t interact with other programs on the computer. Also, you never know exactly what kind of setup the user has, so you can’t really be sure whether your program will work.

This is where server-side programming comes in. In a pure server-side programming environment, all the action happens on the Web server. The user thinks she’s asking for a Web page like normal, but the address really goes to a computer program. The program does some magic and produces a Web page. The user sees a Web page, perhaps never knowing this wasn’t a regular Web page, but a page that was produced instead by a program.

A program running on a Web server has some really nice advantages, such as

♦ A server-side program can access the local file system. Asking a server program to load and save files on the server is no problem at all.

♦ A server-side program can call external programs. This is a very big deal because many Web applications are really about working with data. Database programs are very important to modern Web development. See Book VI for much more on this.

♦ All the user sees is ordinary XHTML. You can set up your program to do whatever you want, but the output is regular XHTML. You don’t have to worry about what browser the user has, or whether he has a Mac, or what browser version he’s using. Any browser that can display XHTML can be used with PHP.

Serving your programs

When using a browser to retrieve Web pages, you send a request to a server. The server then looks at the extension (.html, .php, .js, and so on) of your requested file and decides what to do. If the server sees .html or .js, it says, “Cool. Nothing doing here. Just gotta send her back as is.” When the server sees .php, it says, “Oh, boy. They need PHP to build something here.”

The server takes the page and hollers for PHP to come along and construct the requested Web page on the fly. PHP goes through and looks at the programmer’s blue print and then constructs the working page out of XHTML.

The server then takes that page from PHP and sends back plain XHTML to the client for the browser to display to the user.

When you write PHP programs, a Web server must process the form before the browser can see it. To test your PHP programs, you need to have a Web server available and place the file in a specific place on your computer for the server to serve it. You can’t run a PHP file directly from your desktop. It must be placed in a special place — often, the htdocs or public_html directory under the server.

Picking a language

There are all sorts of different ways to go about dynamically creating Web pages with server-side programming. Back in the day when the Internet was still in diapers, people used things like Perl and CGI scripting to handle all their server-side programming. Eventually, people placed more and more demand on their Web sites, and soon these technologies just weren’t enough.

The prevalent languages today are

♦ ASP.NET: Microsoft’s contender

♦ Java: The heavyweight offering from Sun Microsystems

♦ PHP: The popular language described in this minibook

ASP.NET

ASP.NET is event-driven, compiled, and object-oriented. ASP.NET replaced the ’90s language ASP