cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: How to write applications with flowscripts (WAS Re: [RT] Flowmaps)
Date Fri, 21 Jun 2002 12:14:43 GMT

Ovidiu Predescu wrote:
> On 6/20/02 1:06 AM, "Nicola Ken Barozzi" <> wrote:


> It may actually be better if we have a separate section in the sitemap for
> such scripts that implement business logic. This would help in separating
> what is business logic and what are flow scripts.
> In addition, it could also help in runtime optimizations. For example, the
> Rhino JavaScript engine has two modes of execution, an interpreted one and a
> compiled one. In the compiled mode, the JavaScript scripts are compiled to
> Java bytecodes, so they execute at the same speed as normal Java code. In
> the interpreted mode, an internal set of bytecodes are used, whose execution
> is evidently slower than the compiled mode. The modified Rhino version with
> continuations support works only in interpreted mode (it's actually
> impossible to have it work in the compiled mode, but this is a different
> story).
> So I think it makes sense to have a special section in the sitemap for
> including scripts which act as business logic. With JavaScript scripts for
> example, we can have these running in compiled mode, while flow scripts,
> which are usually smaller, execute in interpreted mode. From a functional
> point of view however, these scripts should be visible to the flow scripts.
> <map:applications>
>  <map:application name="shopping-cart">
>   <map:script src="cart.js" language="JavaScript"/>
>  </map:application>
>  <map:application name="calculator">
>   <map:script src="" language="Python"/>
>  </map:application>
> </map:application>


> We need to figure out how flow scripts are associated with the business
> logic scripts, and whether it makes sense to have the same flow script
> associated with multiple business logic scripts.
> I think this would also make fit nicely with Cocoon blocks, as it makes
> things very modular.
> Do you think having such support makes sense?

I think id does :-)

This would solve these problems at least:

- formalize the MVC pattern which is nice to get one's mouth full but is 
never fully done. MVC is conceptually simple, yet powerfull. This would 
finally stop any phrase like:" I prefer to use Struts because it's MVC". 
*This* is real MVC.

- make use of different optimizations in each MVC domain, ie
*Separation of Concerns*. Till now, the sitemap has been use as a big 
state-type controller, and hacked in many ways. This has mixed concerns 
that should remain separate, ie business logic and flow.

- reduce scope of components making reuse more possible. It's a fact 
that when a component wants to be everything to everyone it sometimes 
gets difficult to reuse it in a non-thought-before approach.
This way we have a more "domained" reuse (M||V||C) that makes sense.

Now the hard parts are making this business part rolling and how to 
control it from the flow...

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

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

View raw message