Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: 
 <C13761ADA42CD311BA050008C75B81210682D3@njmail.woodbridge.agency.com>
From: Jason Reid <jreid@agency.com>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: [RT] Layout-driven vs. content-driven
Date: Fri, 3 Mar 2000 10:40:02 -0500 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

> What the crap is an anti-pattern anyway???

At least this one I can answer.

A Design Pattern is the description of a solution to a 
problem that occurs over and over again in our discipline.
The solution is one that can be used over and over again,
without never necessarily doing it the same way twice.
The Canonical Design Patterns, which are documented in
"Design Patterns: Elements of Reusable Object-Oriented
Software", include such constructs as Abstract Factory,
Composite, and Command Object.

All Design Patterns have benefits and consequences.
AntiPatterns are related to Design Patterns in that they
appear to be reusable solutions to specific types of
problems.  However, the difference between an AntiPattern
and a Design Pattern is that an AntiPattern's consequences
outweighs its benefits.  Most of the documented AntiPatterns
(first done in AntiPatterns : Refactoring Software, Architectures,
and Projects in Crisis) seem obvious to seasoned programmers,
and include constructs such as Spaghetti Code and Design by
Committee.

Basically, AntiPatterns create work to solve non-existant
problems, or they solve problems while creating a whole
other bunch of them.


	>	Jason Reid
		Technical Consultant
		AGENCY.COM
		100 Woodbridge Center Drive, Suite 102
		Woodbridge, NJ 07095
		E jreid@agency.com
		http://www.agency.com


-----Original Message-----
From: Mike Engelhart [mailto:mengelhart@earthtrip.com]
Sent: Friday, March 03, 2000 10:25 AM
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Layout-driven vs. content-driven


Niclas Hedhman wrote:
> 
> I just read an article by Michael Leventhal
> (http://xml.com/pub/au/Leventhal_Michael) regarding XSL in general, and FO
in
> particular.
> 
> It is a bit old, but I think it is relevant in our context.
> 
> http://xml.com/xml/pub/1999/05/xsl/xslconsidered_1.html
> (terribly slow site...)
> 
> Sad(?) to say; he managed to convince me on a lot of points.
> 
> The article put forward some challenges, and I would like to see what kind
of
> arguments the Cocoon users/developers have to defend their choice, or have
we
> all
> been blinded by a "XSL anti-pattern"??
> 
> I realize there is great risk of flames in this subject, BUT any comments?
> 
> Niclas

I read the first page of the article and gave up.  First of all it is very
out of date (1 year old exactly).  Second the author is talking about
client-side XSL transformation vs. client-side transformation using CSS
which has nothing (at this point) to do with Cocoon or the Cocoon process of
site development/publishing.  His points were not convincing at all from the
start.  Anyone who has attempted in even the smallest way to implement a
site relying on client side transformation even using the latest browsers
realizes that doing this creating a world of pain for themselves.  Writing a
shitload of javascript to do simple formatting for the multitude of browsers
out there is a complete waste of time.  I still think XSLT and Cocoon have
some difficult aspects and I plan on writing a summary of these once I
finish my site but on the whole it is the single best model for site
development that uses w3c standards (and - bonus - OSS) that  I have come
across in my several years of web development.

What the crap is an anti-pattern anyway???