>brings me back to my original point: there isn't
>really a standard and I think there ought to be.
You know, a particular idea has occurred to me more than once over the last
year or so whenever documentation and standardization issues arise in this
group. The idea is that the Fusebox methodology would lend itself
beautifully to a Pattern Language, a la Christopher Alexander, the Gang of
Four, etc.
Have any of you spent time with Ward Cunningham's Wiki Wiki Web, and the
Portland Pattern Repository?
<http://c2.com/cgi-bin/wiki?PortlandPatternRepository>
Bruce Eckel, author of Thinking in Java, is currently working on a book
called Thinking in Patterns. He gives this nice definition of the concept:
"Probably the most important step forward in object-oriented design is the
"design patterns" movement, chronicled in Design Patterns, by Gamma, Helm,
Johnson & Vlissides (Addison-Wesley, 1995).[1] That book shows 23 different
solutions to particular classes of problems.
"Initially, you can think of a pattern as an especially clever and
insightful way of solving a particular class of problems. That is, it looks
like a lot of people have worked out all the angles of a problem and have
come up with the most general, flexible solution for it. The problem could
be one you have seen and solved before, but your solution probably didn't
have the kind of completeness you'll see embodied in a pattern.
"Although they're called "design patterns," they really aren't tied to the
realm of design. A pattern seems to stand apart from the traditional way of
thinking about analysis, design, and implementation. Instead, a pattern
embodies a complete idea within a program, and thus it can sometimes appear
at the analysis phase or high-level design phase. This is interesting
because a pattern has a direct implementation in code and so you might not
expect it to show up before low-level design or implementation (and in fact
you might not realize that you need a particular pattern until you get to
those phases).
"The basic concept of a pattern can also be seen as the basic concept of
program design: adding a layer of abstraction. Whenever you abstract
something you're isolating particular details, and one of the most
compelling motivations behind this is to separate things that change from
things that stay the same. Another way to put this is that once you find
some part of your program that's likely to change for one reason or
another, you'll want to keep those changes from propagating other changes
throughout your code. Not only does this make the code much cheaper to
maintain, but it also turns out that it is usually simpler to understand
(which results in lowered costs)."
-- <http://www.mindview.net/TIPatterns/index.html>
I've been working with Wiki Webs for about a year with several different
groups, both programming and non-programming, and have found that the
format can be very productive when you have a participative community --
which we certainly do have here!
Wiki Webs are different from email lists or forums in that they have a
distinct focus on editing and rewriting ideas as a group until a
comfortable document starts to emerge that reflects various perspectives.
Formalizing a Pattern takes the group's documentation a step further and
condenses it into a formal statement of a tried and true solution to a
problem that occurs in a particular setting.
The way Ward Cunningham's group has approached this with the PPR is in a
very ad hoc fashion, processing issues and problems as they occur, rather
than setting out to create a complete documentation system, but the end
result is a very rich, if sometimes very "in process" resource.
Formalizing patterns is a good thing to do on a periodic basis when you
have face-to-face events that bring together a group of participants in an
away-from-work environment. The International Conferences on Pattern
Languages of Programs (a.k.a. PLoP) make pattern development a major part
of their annual conference, and I believe some other programming
communities are beginning to try this as well. Typically, individuals will
take responsibilitly for drafting a proposed pattern, or proto pattern,
drawing from the ad hoc group work on the wiki. When everyone is together
at the conference, short jam sessions can be held to work through the
definition and come to consensus on the formula. Then it goes into the
group's pattern language repository.
The whole concept is a bit hard to explain, but I think if you take a look
at the two links I've mentioned here, you'll get the idea pretty quickly.
If a reasonable amount of interest were to emerge around trying to start a
Fusebox Pattern Repository, I'd be happy to be involved somehow. (I've been
wanting to do a Fusebox wiki wiki app, but haven't had time, or felt I had
the expertise to do it yet, but the Perl app is quite stable.)
regards,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
