cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: Flow wishlist :)
Date Thu, 05 Dec 2002 07:23:48 GMT
Hi Chris,

[Long time, no see, good to hear back from you ;)]

On Tuesday, Nov 26, 2002, at 20:35 US/Pacific, Christopher Oliver wrote:

> Ovidiu Predescu wrote:
>>> Flow is designed to simplify the sitemap
>>> by reducing the amount of routing components required and by moving
>>> business logic out of the sitemap.  Having global flow script 
>>> variables
>>> available to routing components might encouarage users to move the
>>> flow/routing control back into the sitemap. Perhaps this is a "best 
>>> practice"
>>> issue, that we dont have to enforce?
>>> Ideally, with business logic moved to the flow controller, one would 
>>> only
>>> need to use selectors after a generator has been set.
>> The need Marcus originally had was to access the values of the global 
>> variables of a flow script in the view layer. The idea is to avoid 
>> having to explicitly pass these values in the context object of 
>> sendPage*(). Instead one could use something like <jpath:value-of 
>> select="variableName" global="true"/>, where 'variableName' is a 
>> global variable in the flow scripts.
>> These variables could be accessible to sitemap components, but they 
>> should not be abused. They should only be used during the View 
>> generation. They should not be used to do routing, e.g. in selectors 
>> and matchers.
> Um, this sounds extremely bad to me. The use of global variables at 
> all should be discouraged in "flowscripts" for the usual reasons. 
> Allowing access to them in outside of the context of the script itself 
> sounds like an even worse abuse to me. Passing the objects you want to 
> be accessible to the view layer explicitly in sendPage*() was a better 
> design, in my opinion.

You're right, global variables are a bad idea. I think one of the 
reasons they're so bad in this context is that enforce a much stricter 
contract between the flow scripts and the View layer. With the current 
approach the only contract between a View page template and the control 
flow script is specified in the sendPage*() functions. Adding global 
variables changes this simple contract, and makes it difficult for the 
control flow developer to change global variables as (s)he wishes.

> Instead of putting in "convenience" features like this I think it 
> would be more valuable to make other view layers (Velocity, JSP's) 
> accessible to the flow layer. If someone familiar with the internals 
> of Cocoon wants to help me out I'd be interested in contributing to 
> this.

I could help you here. You've already done work for Velocity, it's just 
a matter of integrating them in the current system.

With respect to JSP, I think we can directly use JSTL which has 
strikingly similar features as the JPath logicsheet. The only 
difference is that instead of an XPath notation to access objects, it 
uses a dotted notation. Other than that the features are very similar.


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

View raw message