cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
Subject Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Date Thu, 06 Nov 2003 13:39:53 GMT
Stefano Mazzocchi wrote:

>
> On Wednesday, Nov 5, 2003, at 13:41 Europe/Rome, Vadim Gritsenko wrote:

...

>> Before we vote: how to resolve "flow actions" issue then? There 
>> should be migration path for users who already have wrote an actions 
>> wtih flow.
>>
>> (remember? you've said that actions should be replaced with 
>> flowscript ;-)
>
>
> You teaser ;-)
>
> IMVHO, an action is an overlap of three concerns:
>
>  1) processing logic external to the sitemap used to drive its flow
>  2) processing logic external to the pipelines used to drive its creation
>  3) processing logic used to update the external environment
>
> A potential migration strategy is:
>
>  1) should be done in the flow, either rewriting in javascript or 
> refactoring the logic, moving it into an isolated component (either 
> avalon or simple java class to instantiate from the flow)
>
>  3) this should be refactored into a class or component
>
> which leaves us with 2).
>
> I've seen far too many actions that set parameters that are later used 
> by selectors. This is WRONG!!! You should be writing a selector!!!
>
> But at the very end, I think the issues at stake are orthogonal: Unico 
> and I want a simple way to generate reponses with empty-payloads 
> because this is going to be common for more complex uses of HTTP.
>
> You propose to clone the ugly action-like sitemap semantics with 
> flowscript logic.


No, I don't. I'm just teasing ;-)

I'd like to see following:

1) If flow calls sendPage*(), sitemap execution terminates.
2) If flow calls sendStatus(), sitemap execution terminates.
3) If flow does none of the above, sitemap execution continues.

I think we have already consensus on (1) and (2). (3) is the current 
behavior which can stay.

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.

Vadim



Mime
View raw message