From Ajax Patterns

Evidence: How much real-world evidence for this pattern. 0/2, 1/2, 2/2.

Tags: Tags that summarise the pattern. All will eventually be converted to [Technorati tags](http://www.technorati.com/help/tags.html)

Contents 1 In a Blink 2 Inital State 3 Problem 4 Goal Story 5 Forces 6 Solution 7 Decisions 8 Real-World Examples 9 Code Example 10 Refactoring Illustration 11 Alternatives 12 Related Patterns 13 Visual Metaphor 14 Want to Learn More? 15 Acknowledgements

In a Blink

Eventually, a hand-drawn sketch to set the scene for this pattern.

Inital State

Where the pattern applies (might change name to "Where It Applies")

Problem

The problem this pattern solves.

Goal Story

A typical story that will be made possible once this pattern has been implemented. Each story is based on a persona - a ficticious person. Doing so makes the story a bit more realistic (and, quite frankly, lets the description tiptoe around awkward gender-neutral language!).

The following personae are used. As you'll see, the names reflect the roles they play. It's a bit cheesy, but helps to remember what these people about without having to refer back here.

• Bill is a Bill-paying citizen with a wife, 2 kids, and a dog named after a contemporary sitcom character.
• Frank is a Factory floor manager, often stressing about machine safety and worker productivity.
• Pam is a Project Manager for a perpetually overdue IT project.
• Reta is a Retailer of high-class fashions.
• Stuart is a Student with plenty of time for music and other hobbies not related in any way to his studies.
• Stephanie is another Student, and also Stuart's love interest.
• Tracy is a fast-paced financial Trader, dealing in any asset type where there's a buck to be made.

Forces

The forces which make the problem difficult to solve.

Solution

A 1-2 sentence summary. ... Followed by a general elaboration, including implementation details, rationale, programming aspects, caveats, and gotchas.

Decisions

Each decision is posed as a question. The decisions are not a question-and-answer section to help clarify the solution - that material would belong in the solution itself. Instead, they are "reusable decisions". That is, decisions which will probably arise once you decide to incorporate this pattern. There is no precise answer given, because each decision must be made pragmatically. The description can only guide you in making the decision, first and foremost by simply flagging that the decision is there to be made. And beyond that, by alerting you to the variables involved and the consequences of going in one direction or the other.

Real-World Examples

Real-world examples of the pattern at work. Where real-world evidence is lacking, proof-of-concepts are used instead. Some examples may not be strictly Ajaxian, but included to illustrate a particular point.

Code Example

A code example

Refactoring Illustration

Some patterns cover the coding topics in terms of a refactoring illustration. Refactoring is more in line with reality, since you rarely start working on a system from scratch. Note that Martin Fowler originally defined "refactoring" as a code change without any user-observable behaviour change. I am using the broader definition, now in common industry parlance, of a a bite-sized, incremental, improvement, which may well be noticeable in userland.

The ajaxpatterns.org demos are organised around this concept. For most of the examples, there is an initial, "embryonic", Ajaxian application. Then, there are several parallel refactorings applied to the same demo, each retained in a separate subdirectory. And each of these refactorings may have a further refactoring applied, contained in a deeper subdirectory. What emerges on the site is a tree structure, with the prorgram having evolved in different ways.

For example, look at one "strain" of the "sum" demo: Cache With Expiry, whose origins are evident in its URL ending: /sum/xml/

• [/run/sum/]: First, there is the basic [/run/sum/ sum demo] at /sum/. Enter some numbers

and the server responds with a sum. As a basic Ajaxian application - with no form submission involved - there are some foundational technologies illustrated here, but that's about it.

• [/run/sum/xml/]: Next, the sum is refactored to receive results in XML form. Structured XML Response at work.
• [/run/sum/xml/cache]: One benefit of the new XML form is its convenience for caching, so a further evolution is a

basic cache. A refactoring illustration for the Browser-Side Cache pattern.

• [/run/sum/xml/cache/expiry]: Finally, the cache undergoes a further improvement. This time, a concession to the laws of physics is made, and the cache is now of finite size. Unused elements expire. So here's a further refactoring illustration for Browser-Side Cache.

In most cases, there's only one level of refactoring from the basic demo. Compare the cache exmaple to another "legacy" of the basic sum demo, the [/run/sum/uniqueURL/ Distinct URL demo].

• [/run/sum/]: Again, the starting point is thew basic sum demo.
• [/run/sum/uniqueURL]: Now, the basic sum is refactored in a different direction, to illustrate the Unique URLs pattern.

So the difference from one directory to another is usually quite small. In many cases, the delta provides a tightly-focused illustration of just one or two patterns.

Alternatives

Patterns in this collection, as well as other patterns and anti-patterns, which solve the same problem in a different way.

Related Patterns

Patterns in this collection that are somehow related to this pattern, other than the alternative patterns which would have appeared in the previous section. For example, two patterns may share a common technology or may complement each other particularly well.

Visual Metaphor

A visual metaphor is proposed to firmly [1]

Want to Learn More?

Links to any original references, as well as any other relevant material.

Acknowledgements

Most patterns in the collection were discovered, not created. As well as the examples above, this section is a place where people can be acknowledged for their contributions.