AJAX and PHP

This article is an sample chapter from the Packt Publishing book AJAX and PHP: Building Responsive Web Applications. This is chapter 1 which looks at AJAX and the Future of Web Applications.

Cristian Darie Bogdan Brinzarea Filip Chereches-Tosa Mihai Bucica

Chapter 1

"AJAX and the Future of Web Applications"

In this package, you will find:
A Biography of the authors of the book
A preview chapter from the book, Chapter 1 "AJAX and the Future of Web Applications"
A synopsis of the book's content
Information on where to buy this book

About the Authors

Cristian Darie is a software engineer with experience in a wide range of modern technologies, and the author of numerous technical books, including the popular "Beginning E-Commerce" series. Having worked with computers since he was old enough to press the keyboard, he initially tasted programming success with a first prize in his first programming contest at the age of 12. From there, Cristian moved on to many other similar achievements, and now he is studying distributed application architectures for his PhD degree. He always loves hearing feedback about his books, so don't hesitate dropping a "hello" message when you have a spare moment. Cristian can be contacted through his personal website at www.cristiandarie.ro.

Bogdan Brinzarea has a strong background in Computer Science holding a Master and Bachelor Degree at the Automatic Control and Computers Faculty of the Politehnica University of Bucharest, Romania and also an Auditor diploma at the Computer Science department at Ecole Polytechnique, Paris, France.

His main interests cover a wide area from embedded programming, distributed and mobile computing, and new web technologies. Currently, he is employed as an Alternative Channels Specialist at Banca Romaneasca, Member of National Bank of Greece, where he is responsible for the Internet Banking project and coordinates other projects related to security applications and new technologies to be implemented in the banking area.

Filip Chereches-Tosa is a web developer with a firm belief in the future of web-based software. He started his career at the age of 9, when he first got a Commodore 64 with tape-drive. Back home in Romania, Filip runs a web development company named eXigo www.exigo.ro, which is actively involved in web-based application development and web design. He is currently a student at the University of Oradea, studying Computer Science, and also an active member of the Romanian PHP Community www.phpromania.net.

Mihai Bucica started programming and competing in programming contests (winning many of them), all at age twelve. With a bachelor's degree in computer science from the Automatic Control and Computers Faculty of the Politehnica University of Bucharest, Romania, Bucica works on building communication software with various electronic markets.

Even after working with a multitude of languages and technologies, Bucica's programming language of choice remains C++, and he loves the LGPL word. Mihai also co-authored Beginning PHP 5 and MySQL E-Commerce and he can be contacted through his personal website, www.valentinbucica.ro

1. AJAX and the Future of Web Applications

"Computer, draw a robot!" said my young cousin to the first computer he had ever seen. (Since I had instructed it not to listen to strangers, the computer wasn't receptive to this command.) If you're like me, your first thought would be "how silly" or "how funny"-but this is a mistake. Our educated and modeled brains have learned how to work with computers to a certain degree. People are being educated to accommodate computers, to compensate for the lack of ability of computers to understand humans. (On the other hand, humans can't accommodate very well themselves, but that's another story.)

This little story is relevant to the way people instinctively work with computers. In an ideal world, that spoken command should have been enough to have the computer please my cousin. The ability of technology to be user-friendly has evolved very much in the past years, but there's still a long way till we have real intelligent computers. Until then, people need to learn how to work with computers-some to the extent that they end up loving a black screen with a tiny command prompt on it.

Not incidentally, the computer-working habits of many are driven by software with user interfaces that allow for intuitive (and enjoyable) human interaction. This probably explains the popularity of the right mouse button, the wonder of fancy features such as drag and drop, or that simple text box that searches content all over the Internet for you in just 0.1 seconds (or so it says). The software industry (or the profitable part of it, anyway) has seen, analyzed, and learned. Now the market is full of programs with shiny buttons, icons, windows, and wizards, and people are paying a lot of money for them.

What the software industry has learned is that the equivalent of a powerful engine in a red sports car is usability and accessibility for software. And it's wonderful when what is good from the business point of view is also good from a human point of view, because the business profits are more or less proportional to customers' satisfaction.

We plan to be very practical and concise in this book, but before getting back to your favorite mission (writing code) it's worth taking a little step back, just to remember what we are doing and why we are doing it. We love technology to the sound made by each key stroke, so it's very easy to forget that the very reason technology exists is to serve people and make their lives at home more entertaining, and at work more efficient.

Understanding the way people's brains work would be the key to building the ultimate software applications. While we're far from that point, what we do understand is that end users need intuitive user interfaces; they don't really care what operating system they're running as long as the functionality they get is what they expect. This is a very important detail to keep in mind, as many programmers tend to think and speak in technical terms even when working with end users (although in a typical development team the programmer doesn't interact directly with the end user). If you disagree, try to remember how many times you've said the word database when talking to a non-technical person.

By observing people's needs and habits while working with computer systems, the term software usability was born-referring to the art of meeting users' interface expectations, understanding the nature of their work, and building software applications accordingly.

Historically, usability techniques were applied mainly to desktop applications, simply because the required tools weren't available for web applications. However, as the Internet gets more mature, the technologies it enables are increasingly potent.

Modern Internet technologies not only enable you to build a better online presence, but also allow building better intranet/dedicated applications. Having friendly websites is crucial for online business, because the Internet never sleeps, and customers frequently migrate to the next "big thing" that looks better or feels to move faster. At the same time, being able to build friendly web interfaces gives alternative options for intranet software solutions, which were previously built mainly as desktop applications.

Building user-friendly software has always been easier with desktop applications than with web applications, simply because the Web was designed as a means for delivering text and images, and not complex functionality. This problem has gotten significantly more painful in the last few years, when more and more software services and functionality are delivered via the Web.

Consequently, many technologies have been developed (and are still being developed) to add flashy lights, accessibility, and power to web applications. Notable examples include Java applets and Macromedia Flash, which require the users to install separate libraries into their web browsers.

Delivering Functionality via the Web

Web applications are applications whose functionality is processed on a web server, and is delivered to the end users over a network such as the Internet or an intranet. The end users use a thin client (web browser) to run web applications, which knows how to display and execute the data received from the server. In contrast, desktop applications are based on a thick client (also called a rich client or a fat client), which does most of the processing.

Web applications evolve dreaming that one day they'll look and behave like their mature (and powerful) relatives, the desktop applications. The behavior of any computer software that interacts with humans is now even more important than it used to be, because nowadays the computer user base varies much more than in the past, when the users were technically sound as well. Now you need to display good looking reports to Cindy, the sales department manager, and you need to provide easy-to-use data entry forms to Dave, the sales person.

Because end-user satisfaction is all that matters, the software application you build must be satisfactory to all the users that interact with it. As far as web applications are concerned, their evolution-to-maturity process will be complete when the application's interface and behavior will not reveal whether the functionality is delivered by the local desktop or comes through fiber or air. Delivering usable interfaces via the Web used to be problematic simply because features that people use with their desktop application, such as drag and drop, and performing multiple tasks on the same window at the same time, were not possible.

Another problem with building web applications is standardization. Today, everything web-accessible must be verified with at least two or three browsers to ensure that all your visitors will get the full benefit of your site.

Advantages of Web Applications

Yes, there are lots of headaches when trying to deliver functionality via the Web. But why bother trying to do that in the first place, instead of building plain desktop applications? Well, even with the current problems that web applications have with being user-friendly, they have acquired extraordinary popularity because they offer a number of major technological advantages over desktop applications.

• Web applications are easy and inexpensive to deliver. With web applications, a company can reduce the costs of the IT department that is in charge of installing the software on the users' machines. With web applications, all that users need is a computer with a working web browser and an Internet or intranet connection.
• Web applications are easy and inexpensive to upgrade. Maintenance costs for software have always been significant. Because upgrading an existing piece of software is similar to installing a new one, the web applications' advantages mentioned above apply here as well. As soon as the application on the server machine is upgraded, everyone gets the new version.
• Web applications have flexible requirements for the end users. Just have your web application installed on a server-any modern operating system will do-and you'll be able to use it over the Internet/Intranet on any Mac, Windows, or Linux machine and so on. If the application is properly built, it will run equally well on any modern web browser, such as Internet Explorer, Mozilla Firefox, Opera, or Safari.
• Web applications make it easier to have a central data store. When you have several locations that need access to the same data, having all that data stored in one place is much easier than having separate databases in each location. This way you avoid potential data synchronization operations and lower security risks.

In this book we'll further investigate how to use modern web technologies to build better web applications, to make the most out of the possibilities offered by the Web. But before getting into the details, let's take a short history lesson.

Building Websites Since 1990

Although the history of the Internet is a bit longer, 1991 is the year when HyperText Transfer Protocol (HTTP), which is still used to transfer data over the Internet, was invented. In its first few initial versions, it didn't do much more than opening and closing connections. The later versions of HTTP (version 1.0 appeared in 1996 and version 1.1 in 1999) became the protocol that now we all know and use.

HTTP and HTML

HTTP is supported by all web browsers, and it does very well the job it was conceived for- retrieving simple web content. Whenever you request a web page using your favorite web browser, the HTTP protocol is assumed. So, for example, when you type www.mozilla.org in the location bar of Firefox, it will assume by default that you meant http://www.mozilla.org.

The standard document type of the Internet is HyperText Markup Language (HTML), and it is built of markup that web browsers understand, parse, and display. HTML is a language that describes documents' formatting and content, which is basically composed of static text and images. HTML wasn't designed for building complex web applications with interactive content or user-friendly interfaces. When you need to get to another HTML page via HTTP, you need to initiate a full page reload, and the HTML page you requested must exist at the mentioned location, as a static document, prior to the request. It's obvious that these restrictions don't really encourage building anything interesting.

Nevertheless, HTTP and HTML are still a very successful pair that both web servers and web clients (browsers) understand. They are the foundation of the Internet as we know it today. Figure 1.1 shows a simple transaction when a user requests a web page from the Internet using the HTTP protocol:



Three points for you to keep in mind:

1. HTTP transactions always happen between a web client (the software making the request, such as a web browser) and a web server (the software responding to the request, such as Apache or IIS). From now on in this book, when saying 'client' we refer to the web client, and when saying 'server' we refer to the web server.
2. The user is the person using the client.
3. Even if HTTP (and its secure version, HTTPS) is arguably the most important protocol used on the Internet, it is not the only one. Various kinds of web servers use different protocols to accomplish various tasks, usually unrelated to simple web browsing. The protocol we'll use most frequently in this book is HTTP, and when we say 'web request' we'll assume a request using HTTP protocol, unless other protocol will be mentioned explicitly.

Sure thing, the HTTP-HTML combination is very limited in what it can do-it only enables users to retrieve static content (HTML pages) from the Internet. To complement the lack of features, several technologies have been developed.

While all web requests we'll talk about from now on still use the HTTP protocol for transferring the data, the data itself can be built dynamically on the web server (say, using information from a database), and this data can contain more than plain HTML allowing the client to perform some functionality rather than simply display static pages.

The technologies that enable the Web to act smarter are grouped in the following two main categories:

• Client-side technologies enable the web client to do more interesting things than displaying static documents. Usually these technologies are extensions of HTML, and don't replace it entirely.

• Server-side technologies are those that enable the server to store logic to build web pages on the fly.

PHP and Other Server-Side Technologies

Server-side web technologies enable the web server to do much more than simply returning the requested HTML files, such as performing complex calculations, doing object-oriented programming, working with databases, and much more.

Just imagine how much data processing Amazon must do to calculate personalized product recommendations for each visitor, or Google when it searches its enormous database to serve your request. Yes, server-side processing is the engine that caused the web revolution, and the reason for which Internet is so useful nowadays.

The important thing to remember is that no matter what happens on the server side, the response received by the client must be a language that the client understands (obviously)-such as HTML,which has many limits, as mentioned earlier.

PHP is one of the technologies used to implement server-side logic. Chapter 3 will serve an introduction to PHP, and we'll use PHP in this book when building the AJAX case studies. It's good to know, though, that PHP has many competitors, such as ASP.NET (Active Server Pages, the web development technology from Microsoft), Java Server Pages (JSP), Perl, ColdFusion, Ruby on Rails, and others. Each of these has its own way of allowing programmers to build server-side functionality.

PHP is not only a server-side technology but a scripting language as well, which programmers can use to create PHP scripts. Figure 1.2 shows a request for a PHP page called index.php.This time, instead of sending back the contents of index.php, the server executes index.php and sends back the results. These results must be in HTML, or in other language that the client understands.



On the server side you'll usually need a database server as well to manage your data. In the case studies of this book we'll work with MySQL, but the concepts are the same as any other server. You'll learn the basics of working with databases and PHP in Chapter 3.

However, even with PHP that can build custom-made database-driven responses, the browser still displays a static, boring, and not very smart web document.

The need for smarter and more powerful functionality on the web client generated a separated set of technologies, called client-side technologies. Today's browsers know how to parse more than simple HTML. Let's see how.

JavaScript and Other Client-Side Technologies

The various client-side technologies differ in many ways, starting with the way they get loaded and executed by the web client. JavaScript is a scripting language, whose code is written in plain text and can be embedded into HTML pages to empower them. When a client requests an HTML page, that HTML page can contain JavaScript. JavaScript is supported by all modern web browsers without requiring users to install new components on the system.

JavaScript is a language in its own right (theoretically it isn't tied to web development), it's supported by most web clients under any platform, and it has some object-oriented capabilities. JavaScript is not a compiled language so it's not suited for intensive calculations or writing device drivers and it must arrive in one piece at the client browser to be interpreted so it is not secure either, but it does a good job when used in web pages.

With JavaScript, developers could finally build web pages with snow falling over them, with client-side form validation so that the user won't cause a whole page reload (incidentally losing all typed data) if he or she forgot to supply all the details (such as password, or credit card number), or if the email address had an incorrect format. However, despite its potential, JavaScript was never used consistently to make the web experience truly user friendly, similar to that of users of desktop applications.

Other popular technologies to perform functionality at the client side are Java applets and Macromedia Flash. Java applets are written in the popular and powerful Java language, and are executed through a Java Virtual Machine that needs to be installed separately on the system. Java applets are certainly the way to go for more complex projects, but they have lost the popularity they once had over web applications because they consume many system resources. Sometimes they even need long startup times, and are generally too heavy and powerful for the small requirements of simple web applications.

Macromedia Flash has very powerful tools for creating animations and graphical effects, and it's the de-facto standard for delivering such kind of programs via the Web. Flash also requires the client to install a browser plug-in. Flash-based technologies become increasingly powerful, and new ones keep appearing.

Combining HTML with a server-side technology and a client-side technology, one can end up building very powerful web solutions.

What's Been Missing?

So there are options, why would anyone want anything new? What's missing?

As pointed out in the beginning of the chapter, technology exists to serve existing market needs. And part of the market wants to deliver more powerful functionality to web clients without using Flash, Java applets, or other technologies that are considered either too flashy or heavy-weight for certain purposes. For these scenarios, developers have usually created websites and web applications using HTML, JavaScript, and PHP (or another server-side technology). The typical request with this scenario is shown in Figure 1.3, which shows an HTTP request, the response made up of HTML and JavaScript built programmatically with PHP.



The hidden problem with this scenario is that each time the client needs new data from the server, a new HTTP request must be made to reload the page, freezing the user's activity. The page reload is the new evil in the present day scenario, and AJAX comes in to our rescue.

Next Page