Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <4082B74E.3040502@apache.org>
Date: Sun, 18 Apr 2004 19:13:50 +0200
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Use of flowscript or the pyramid of contracts  (was Re:
 [RT] Checked exceptions considered harmful)
References: <408103CA.105@s-und-n.de> <4081A3B8.1060303@apache.org>
 <4081A615.7060805@apache.org>
In-Reply-To: <4081A615.7060805@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stefano Mazzocchi wrote:

> Guido Casper wrote:
>
>>> Why do "flow people" constantly fall back using Java classes? 
>>
>>
>> In my case, I tried to avoid it as the plague.
>
>
> Sorry, hit the wrong key and sent the email ;-) Let me continue.
>
>> Do they put to much into the flow layer? 
>
>
>> The expectations for the flow layer
>>
>>> seem to be so various. I fear that this fact does more harm than 
>>> good to Cocoon. Hm, I don't even have a definition of "flow layer". 
>>> Why is there no library of flow components readily available? I 
>>> don't know but I suspect it's harder to build reusable flow 
>>> components than it is to build reusable sitemap components (the 
>>> level of component reusability of the sitemap is unparalleled). At 
>>> the same time it is too easy to just get my stuff finished with 
>>> flow. Which is exactly what makes flow currently so powerful and 
>>> what may count in many cases. However this particular advantage may 
>>> be just temporary.
>>
>
> I think that if we come up with with reusable FOM components, we have 
> failed.
>
> on the other hand, I think there are reusable FOM "aspects" that might 
> be reusable, but let's not go there now.
>
> sitemap is declarative glue while flow is procedural glue.
>
> if there is too much spaghetti code in between them, there is 
> something wrong and we have to fix that.
>
> I believe that inputmodules/outputmodules do already pose a 
> significant complexity to the clean separation. I think input modules 
> *are*not* necessary once you have a clearly defined way for flow to 
> pass parameters to the sitemap.


You might be right here but don't forget that it is not always web 
_applications_ why our users take Cocoon. It is very often simple 
_publishing_. Input modules make it *very* easy for them to e.g. read 
out a request parameter without having to go the detour of using flowscript.

-- 
Reinhard