cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Washeim <>
Subject Re: [C2] Package names
Date Sat, 08 Jul 2000 00:43:27 GMT
on 7/7/00 8:54 pm, Stefano Mazzocchi at 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 | ).

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

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 . . .

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) . . .

phew. sorry, I'm being verbose and obtuse. I just heart the wrapper pattern

> [...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

> then the interface for every component category will be placed in
> org.apache.cocoon.[action].[actor]
> Please, PLEASE, let's agree on this.

ok. :)

Thanks for bearing with me...

Mark (Poetaster) Washeim

'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.

Quem colorem habet sapientia?'

Evan S. Connell


View raw message