Datasheet

Part I: Introduction to Python Frameworks

Listing 1-1: Simple Python HTML page generator

print(“Content-type: text/html”)

page = “””

<html>

<head>

<title>Hello World Page!</title>

</head>

<body>

<p>Hello World</p>

</body>

</html>

“””

print page

The answer was both yes and no. In the abstract sense, what every website was striving to do was to

generate HTML code (initially) to present material as a substitute for the printed page, and then (later) as

a substitute for earlier form-based styles that mimicked human interaction. However, there was also an

emerging need to create and maintain transactions for a new style of commerce in which the vendor side

of the equation was entirely autonomous and could support a variety of free-form interactions. For that,

designers had to evolve a style of architecture that clearly separated the manipulation of the underlying

model from the management of the user experience, and from the business logic behind the form. This

led to the rediscovery of the model-view-controller ( MVC ) design center (discussed in more detail in

Chapter 3 ) just in time for the emergence of Web 2.0.

Web 2.0, the Next Generation

The problem with creating applications and tools based on the first set of technologies underlying the

Web was that the user interaction model was really rather wretched. Creating a word-processing tool,

such as Google Documents, would have been difficult, if not impossible. Consider the capabilities that a

typical Web 2.0 word processor exhibits:

❑ Every keystroke and input is reflected on the screen as soon as it happens.

❑ Document modifications are silently persisted into the model, which is online and secured from

the possibility of loss from the failure of an individual PC.

❑ The tool must support a reasonable number of formatting capabilities and enable the insertion

of structured content such as tables or images.

In short, such a tool must be largely indistinguishable from the earlier generation’s RCP equivalent.

The responsiveness that an interactive user needs in such a case could have been partially mimicked in

HTML using HTTP in the Web 1.0 era, but because a write-back to the model could have been accom-

plished only with a synchronous HTTP request, which also would have resulted in a full page refresh,

the experience would have been disorienting for the end user. The result certainly wouldn’t have looked

or performed like a typical RCP. As Figure 1-1 depicts, every outbound call results in a complete

page refresh.