cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Flow wishlist :)
Date Fri, 22 Nov 2002 18:08:58 GMT
Michael Melhem wrote:
> Hi everyone,
> It was great seeing you all in Ghent!!!! :)
> See comments below..
> On Sat, 16 Nov 2002, Sylvain Wallez wrote:
>>My feeling (I won't say "opinion" since I don't master all the details)
>>is that the flow is becoming a first-class Cocoon citizen : it not only
>>calls business logic and sends pages depending on the logic result, but
>>it's also giving information to build these pages, and it also appears
>>that we want to master it's relationship with sitemap mounting, and
>>later blocks.
>>So we need a kind of "flow-values" object (don't know if it's the
>>interpreter or something else) that would be available to components
>>invoked to display the page, be it routing components like matchers and
>>selectors or sitemap components like generators and transformers.
> I agree that flow should be considered a "first class Cocoon citezen"
> but I have some reservations about global flow variables being available
> to sitemap routing components.

yeah, rings a bell here as well.

> Flow is designed to simplify the sitemap
> by reducing the amount of routing components required and by moving
> business logic out of the sitemap.

well, business logic shouldn't be in the sitemap anyway, but in sitemap 
components. What we want to factor out is the flow logic (the logic that 
  determines 'where to go' between one webapp screen and another)

> Having global flow script variables
> available to routing components might encouarage users to move the
> flow/routing control back into the sitemap.

I had the same impression at first, but then, on second thought, I'm not 
sure. In fact, with sendPage*() methods you are already passing 
parameters to the URI. Hmmmm, do you guys have an example where having 
these parameters available to the sitemap components would be a great 
use-case? I'm afraid of FS here, obviously.

> Perhaps this is a "best practice"
> issue, that we dont have to enforce?

We must do *everything* possible to prevent abuse of the flowscript 
layer. In fact, at the Cocoon BOF, several people expressed this concern 
of seeing script kiddies coming from the flash world abusing the 
flowscript and making the whole thing unmaintainable.

> Ideally, with business logic moved to the flow controller, one would only
> need to use selectors after a generator has been set.


>>First, storing it in the session doesn't seem to be a good idea to me,
>>as flow values are request specific. We have however two ways of storing
>>it :
>>- as a request attribute
>>- as a new entry in the object model.
>>As I said above, the flow is becoming a first-class citizen, and we have
>>to define how these values propagate not only to subsitemaps, but also
>>to "cocoon:" sources. For this, my preference goes to adding a new entry
>>in the object model, which will be easier to manage, eventually through
>>flow-related additional attributes on <map:mount>.
> Yes, a method is needed to regulate flow scope with regard to mounted sub
> sitemaps. We may need something like
> <map:mount ... propagate-flow="true" >
> As we discussed earlier, this would be better than having a propagate
> on the flow tag itself, because this way one can control propagation to
> individual sub sitemaps
> Other Issues and Ideas:
> 1. Renaming The Flow Send Functions.
> Its clear from speaking with others that the naming of the flow script
> "sendPage" functions is quite confusing...because infact "sendPageAndContinue"
> has nothing to do with continuations. I propose:
> "sendPage()" be moved to "sendPageAndWait()"
> "sendPageAndContinue()" be moved to "sendPage()".

+100! I had the exact same problem.

> 2. Dynamic Flow Loading.
> The way I see it, the flow controller managers the flow through a set of
> available "views" (pipelines in our case). However, its quite possible that
> in certain situations the flow through this particular set of views will need
> to differ. For example, the flow through the views for a user with the
> profile of "administrator" might be different than for that of "user".

Hmmm, -0.9 it sounds like overseparation of concerns to me (oSoC, it's 
anti-pattern brother). We *want* people to work on the same file, 
otherwise, the flow of the administrator and the one of the users might 
get out of synch.

> I suggest we consider providing the ability for dynamicially loaded
> flow contollers depending on some variable (via inputmodules?)..
> This would mean that the individual flow scrips would be
> simpler because they do not have to cater for all possible situations.
> This would also provide a simple mechanism for flow polymorphism and
> SoC.

I don't see how this can allow flow polymorphism (besides, do we really 
need that?)

> Ok. I think thats enough for now. :)
> Regards,
> Michael Melhem
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

Stefano Mazzocchi                               <>

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

View raw message