Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <3966FD7E.1C514284@apache.org>
Date: Sat, 08 Jul 2000 12:07:58 +0200
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [C2] Package names
References: <B58C45CF.213E%esalon@canuck.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mark Washeim wrote:
> 
> on 7/7/00 8:54 pm, Stefano Mazzocchi at stefano@apache.org wrote:
> 
> > Mark, let me tell you: you are a pain in the ass! :)
> >
> > (it's intended as a compliment)
> >
> 
> Thank you, I'll take it as such. I'm just trying to contribute something
> that doesn't involve my contributing proper code :) Sorry :( I'll get to
> that . . .
> 
> >> Something to think about, if a transformer is both producer/consumer could
> >> it be thought of in terms of the decorator pattern? That is, a wrapper???
> >
> > No, I disagree.
> >
> > A transformer is _both_ a producer and a consumer. So it may be a
> > "generator wrapper" or a "serializer wrapper", depending on how you
> > think about it.
> >
> > By creating the notion of "transformer implements producer, consumer"
> > you have balanced the two views and, IMO, this makes the pipes more
> > balanced.
> >
> 
> Ok, this is exactly how I think of wrappers (decorators). When a series of
> filters must transparently pass, for instance, a binary stream through each
> other, so, to speak, they implement producer, consumer . . . that is also
> why I prefer the word wrapper to decorator, as the decorator name
> 'disguises' the fact of the transformations that may occur if data is
> treated (as opposed to the visual widget example of frames).
> 
> I'm probably being thick, but I just don't see the distinction. The point of
> the wrapper pattern is that is is of such broad applicability (ie, it IS the
> formal representation of the unix | ).

There many different patterns that happen to do _almost_ the same thing

 - decorator
 - facade
 - adaptor
 - pipe & filters

(wrapper is not a GoF official pattern). Some of these patterns may
overlap for 90% of their application area. Sometimes they are even
synonims.

> I'm only curious about this because I have previously designed what is
> tantamount to an application server, on the principle of actions
> implementing wrappers. It has turned out to serve us very well in building
> applications.

ok
 
> I've never gone much beyond it, though, in terms of isolating roles like
> producer and consumer among those object roles which may, in any given
> application compose a larger framework . . .

Sounds familiar :)
 
> That's why I'm curious (and use ???) . . .
> 
> 
> > (unlike SAX2 where a Filter is a generator wrapper, or XSLT where
> > processors are serializer wrappers)
> >
> > Cocoon tries to balance between the two creating an independent
> > component.
> >
> 
> Understood. In the context of the design I refer to earlier, it is the case
> that, what we call action wrappers, may implement both the role of producer
> and consumer. For instance, an action wrapper may 'transparently' pass
> through request context while producing the results of an sql query. The
> action it wraps may do something like, for instance logging. It may also act
> as a serializer (for instance, taking the produced result set and rendering
> xml) or, finally a serializer filter (an instance of an xslt action,
> wrapping another xslt action) . . .

It sounds like painting the cocoon pipeline with a different color...
(nothing offensive, just a 30000 feet view of it)
 
> phew. sorry, I'm being verbose and obtuse. I just heart the wrapper pattern
> :)

You _are_ a naming pain in the ass, dude. I can tell you that :)

> > [...snipped...]
> >
> > Ok, at the end I propose the following naming:
> >
> > verb    |    action      |    actor
> > -----------+----------------+--------------
> > generate  | generation     | generator
> > transform | transformation | transformer
> > serialize | serialization  | serializer
> > select    | selection      | selector
> > match     | matching       | matcher
> 
> +1
> 
> > then the interface for every component category will be placed in
> >
> > org.apache.cocoon.[action].[actor]
> >
> > Please, PLEASE, let's agree on this.
> 
> ok. :)

Good.
 
> Thanks for bearing with me...

It's been a pleasure... NOT! :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------