Datasheet

Chapter 1: Web 2.0, Python, and Frameworks
15
Design Patterns for Web 2.0
In the book Rich Internet Applications: AJAX and Beyond (Wiley Publishing, 2007), the au-
thors present seven crucial high-level design patterns for Web 2.0 developers. They are
repeated here in slightly altered form for your consideration. These are important as-
pects that create the design center for most of the applications you’ll write in this new,
highly net-centric paradigm.
Design Pattern 1: Expose (at Least Some of) the Remote API
RIA developers should create content in such a way that mediating applications which
other developers or end users might dream up can interact with it, display it, or repur-
pose its content. User-level content repurposing is extremely common in the Web 2.0
era in the form of mashups . Mashups and remixes occur when new applications (origi-
nally unintended) are constructed from data and services originally intended for some
other purpose.
Design Pattern 2: Use a Common Data Format
A different (but similar) pattern suggests that RIA developers create data models un-
derlying the service-based applications, so that they or another developer can leverage
them. No matter what format the back-end server uses to store the data model (regard-
less of whether it’s a SQLite relational database, an NFS-mounted, flat-file system, or
an XML data store), the output to the user view should be expressed as something that
any number of readers or parsers can handle.
Design Pattern 3: The Browser Creates the User Experience
In most commercially available browsers, application capabilities are limited only by
the stability, extensibility, and support for JavaScript. You, the developer, can deal with
this limitation because, as a trade-off, it’s a lot better than the tall stack of entry limita-
tions and barriers that drove you crazy during the previous software epoch. If you
need visual sophistication beyond the capability of the modern browser, you can use
other browser-pluggable alternatives, such as Adobe Flash (and write code in Python
on the server side and Flex on the browser side).
Design Pattern 4: Applications Are Always Services
Although this was already mentioned briefly, it’s a sufficiently important design pat-
tern to bear repetition. RIAs are part of a service-oriented architecture (SOA) in which
applications are services, created from scratch or as artifacts from recombining other
application facets. Subject to limitations (such as the availability of some other service
on which your application may depend), SOA creates the software equivalent of evolu-
tionary adaptation. Remarkably, no protocol stack by a committee of desktop vendors
was required to create this pattern. Unlike the UDDI or WDSL stack, the Web 2.0 SOA
is simple and almost intuitive.
Design Pattern 5: Enable User Agnosticism
RIAs won’t force the user to worry about operating systems or browsers. As long as the
browser supports scripting, applications can unobtrusively just do their work. Devel-
opers could choose to take advantage of secret handshakes or other backend imple-
mentations that assure vendor or OS lockdown (and you can probably think of one
browser and one OS vendor that does this), but the downside of making such a devil’s
(continued)