cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Melhem <micha...@fztig938.bank.dresdner.net>
Subject Re: Flow wishlist :)
Date Fri, 22 Nov 2002 12:58:56 GMT
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.

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.

>
> 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()".

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".

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.

Ok. I think thats enough for now. :)

Regards,
Michael Melhem



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message