cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Date Sun, 23 Jun 2002 12:47:39 GMT

Stefano Mazzocchi wrote:
> Nicola Ken Barozzi wrote:
>>>Let's avoid the usual "let's tackle all problems at once" and let's try
>>>to get something hammered down before starting using brain cycles in
>>>some other directions.
>>This is actually part of the hammering down.
>>I was talking about definitions (ie what flowscript isn't), not
> Ok. Here's my vision: a flowscript is the location where you place your
> flow logic. The flow logic is the collection of instructions that
> indicate how to make the transition from one page to another.
> Everything else shouldn't be there.


>>>There are yet many doubts to cover from the flowscript stuff that start
>>>talking about something else makes less sense ATM, IMHO.
>>This is one of them.
>>Flowmaps are so powerfull that all the stuff that was innapropriate to
>>be done in the sitemap (heavy webapps) will automatically slip over to
>>And since it's procedural, it's a *big* concern of mine that flowscript
>>will become the problem-solver catchall.
> I hear you, but since we all agree that business logic shouldn't be in
> the flowscript, I don't understand the need to discuss whether or not
> it's good to have business logic defined in a scripting language.
> This is an entirely separate concern.


>>>So, please, let's place this back on the stack.
>>It's already on the stack underneath, this is part of the flowscript
> It's hard to define what a business logic is, but it's easy to know if
> this has anything to do with describing the transition between pages
> (flow).


>>When you made the sitemap you also talked about what it *isn't*, not
>>only what it *is*.
>>Spitscript is what should stay out of the flowmap.
> No, no, no. With this you are assuming that it's equivalent to use a
> scripting language to describe business logic. This is yet to be
> discussed, but this is an entirely different concern from this
> discussion, thus my call to stop it until we have finished focusing on
> the flowscript.

Ok, I agree.

Let's remember that flowscript is a potential liability in a sense that 
it can be really abused in doing what you and I know it shouldn't do.

BTW, just a RT... this means that we would have MVFC: model, view, flow, 
controller... :-?

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:
For additional commands, email:

View raw message