Pattern Template - Ajax Patterns

Pattern Template

From Ajax Patterns

(Difference between revisions)
Revision as of 17:31, 7 August 2008
65.203.234.66 (Talk | contribs)
restored original acknowledgements text
← Previous diff		 Revision as of 13:48, 8 September 2010
68.191.51.210 (Talk | contribs)

Next diff →
Line 73: Line 73:
-== Headline text ==+ 
-eryye+
-== Headline text =='''Bold text'''eryert+
-------[[User:147.29.225.156|147.29.225.156]] 09:55, 8 May 2007 (EDT)<nowiki>Insert non-formatted text here</nowiki>+
= Real-World Examples = = Real-World Examples =

Revision as of 13:48, 8 September 2010

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.


Contents

In a Blink

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


Initial State

Where it applies (might change name to "Where the pattern 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 with a very real personality. Doing so makes the story a bit more realistic (and, quite frankly, talking about specific people lets me say "he" and "she" instead of obfuscating the text with gender-neutral language!).

A small cast of personae is used throughout the patterns. Their names are mneumoic; they reflect the roles they play. It's a bit cheesy, but helps to remember what these people are about without having to refer back here. First, there are the users who appear in the "Foundational Technologies" and "Functionality and Usability" sections.

  • Bill is a Bill-paying citizen with a wife, 2 kids, and a dog named after a contemporary sitcom character.
  • Doc is a Doctor with geeky tendencies.
  • 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.
  • Sasha is a Socialite with plenty of time for social bookmarking, social blogging, and social tagging.
  • Stuart is a Student with plenty of time for music and other hobbies not related in any way to his studies.
  • Tracy is a fast-paced financial Trader, dealing in any asset type where there's a buck to be made.

Then, there are the developers, who appear throughout the "Programming" and "Development and Deployment" sections.

  • Dave is a senior Developer, skilled in the various Ajax-related technologies.
  • Devi is likewise a senior Developer, also skilled in the various Ajax-related technologies.


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.

yer

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 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. The "xml" prefix on the URL tells you its lineage.
  • /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].

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.


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.

Retrieved from "http://ajaxpatterns.org/Pattern_Template"