cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guido Casper" <>
Subject sitemap design (was: Re: [Vote] empty HTTP responses)
Date Sat, 08 Nov 2003 11:02:30 GMT
Stefano Mazzocchi wrote:
> On 7 Nov 2003, at 17:22, Guido Casper wrote:
>> Stefano Mazzocchi wrote:
>>> On 7 Nov 2003, at 13:52, Vadim Gritsenko wrote:
>>>> Stefano Mazzocchi wrote:
>>>>> On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko
>>>>> wrote:
>>>>>> I agree with comments in this other thread that let's not
>>>>>> introduce nested components in <map:call/>. Instead, if needed,
>>>>>> let's introduce <act type="flow"/>. Sometime later.
>>>>> -1
>>>> Your -1 means: "replace later with never", right? Just to remove
>>>> any possible point of confusion :)
>>> yes. I am against the silly
>>>   <xxx>
>>>    ... do something if true
>>>   </xx>
>>>   .. do something if false
>>> syntax. doesn't matter what the logic that drives the "xxx" tag is
>>> or what "xxx" is remapped to.
>> Wow, that would rule out matchers as well.
>> But it might make some sense since matchers are not all that
>> different to
>> actions ;-)
> Careful. I'm against the use of
>   <match src="something">
>   </match>
>   <read/>
> as well. The proper way should be
>   <match src="something">
>    ...
>   </match>
>   <match src="**">
>    <reader/>
>   </match>
> having the logic processing not following the element nesting, is,
> IMO, very confusing and very bad practice.
> In the original sitemap design, it was *NOT* possible to have pipeline
> components inside <pipeline>, only matchers. This is something that
> was introduced while I wasn't watching, just like actions.
> Yes, actions are not the only the only things I dislike about the
> sitemap: the tree processor introduced new ways of dealing with things
> (like having resources without generators or serializers, or pipeline
> components in pipelines without matchers)... but all these things
> ended up being more harm than good from a usage perspective.
> So, what's the point of introducing something and then come out with
> "best practices" that prevent you from using them?

Sorry if I added confusion.

Yes, "best practices" has always been hard to come up with for Cocoon. This
certainly has to do with the variety of usages users come up with. "Best
practices" tend to have a short life anyway.

I always wondered what the real difference between actions and matchers is
and (thanks to the power of expressive names) came to the conclusion that
it's the silent consensus to keep matchers side effect free while the side
effect of actions is their primary purpose.

You seem to be with Rickard Öberg's third principle for making software
"A framework's power comes not from what it allows, but from what it does
not allow"

However this comes just after:
"If you make a decision, be sure that it counts"

I somehow always had the feeling that Cocoon is different and its
unrestrictiveness (is this the right word?) attracts the creatives and it's
unforeseeable what they come up with. Cocoon is not just a framework for
building aplications. It's more of a framework for building frameworks. But
that's just my opinion.


View raw message