3.4. Anatomy of a Pattern All of the patterns follow the same basic format, though certain fields are left out where appropriate. This section explains the meaning of each section.
Evidence How much real-world evidence exists for the pattern, on a 3-point scale and presented graphically? It's a rather subjective estimate, but use the following icons as a guide:
Suggests the idea is purely speculative
Suggests there's at least a proof-of-concept or an early usage
Suggests there's a few established examples
Suggests the pattern is in widespread usage
Tags Tagsor keywords help people locate the pattern and get a sense of its focus.
In a Blink This is a sketch to set the scene for the pattern.
Goal Story, Developer Story A story is a typical scenario to explain how the pattern is used or what the benefit will be to end users. This pattern has been implemented. Each story is based on a "persona"a fictitious person (http://www.evolt.org/article/Practical_Persona_Creation/4090/56111/)to make the story 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 mnemonic in that they reflect the personae's roles. It's cheesy, but it will hopefully help you remember what these people do without having to refer back here. The stories in Foundational Technology Patterns (Part II) and Functionality and Usability Patterns (Part IV) are all "Goal Stories"; they illustrate how users interact with a system once the pattern has been implemented. Here are the personae used in all the Goal Stories:
Bill A Bill-paying citizen with a wife, 2.4 kids, and a dog named after a contemporary sitcom character.
Doc A Doctor with geeky tendencies.
Frank A Factory Floor Manager, often stressing about machine safety and worker productivity.
Pam A Project Manager for a perpetually overdue IT project.
Reta A Retailer of high-class fashions.
Sasha A Socialite with plenty of time for social bookmarking, social blogging, and social tagging.
Stuart A Student with plenty of time for music and other hobbies not related in any way to his studies.
Tracy A fast-paced financial Trader, dealing in any asset type where there's a buck to be made. Then there are the stories in Development Patterns (Part V), which show how a Developer uses a particular pattern. These are present in all the "Programming" and "Development" patterns, reflecting the nature of those sections. There are two aptly named developers who appear throughout these stories:
Dave A senior Developer, skilled in the various Ajax-related technologies.
Devi A senior Developer, also skilled in the various Ajax-related technologies.
Problem The problem that is being addressed.
Forces The forces that arise in addressing the problem.
Solution A brief solution statement (the first sentence of the section), followed by an elaboration of the technique.
Decisions Each decision is posed as a question. The decisions are not a FAQ section to help clarify the solutionsuch material would belong in the solution itself. Instead, they are "reusable decisions"that is, decisions that will often 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 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 and libraries are used instead. Some examples may not be strictly Ajaxian but are included to illustrate a particular point.
Code Example: Refactoring Illustration A code example and walkthrough. Where the system is an Ajax Patterns demo rather than an external application, it's usually a "Refactoring Illustration" because an earlier version is being refactored according to the given pattern. This is explained further at the end of this chapter. Note that Martin Fowler originally defined "refactoring" as a code change without any user-observable behavior change. I am using the broader definition, now in common industry parlance, of a small, incremental improvement, which may well be externally visible.
Alternatives Other patterns that solve the same problem in a different way. These are often, but not always, Ajax Patterns documented elsewhere in this book.
Related Patterns Other Ajax Patterns that are somehow related to this pattern, other than the alternative patterns that would have appeared in the previous section. Usually, this means the Related Pattern is a possible follow-up pattern. It may also mean the patterns are somehow similar; e.g., they rely on the same technology.
Metaphor A metaphor to help remember the pattern. Some people will find this annoying (and should therefore skip over) and others might find it a helpful way to firm up their understanding of the pattern and help remember it later on.
Want to Know More? Links to any original references and other useful material.
Acknowledgments Most patterns in the collection were not just speculations, but were discovered from what others were actually doing. As well as the examples above and the initial Acknowledgments section, this section is a place where people can be acknowledged for their contributions. |
