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.
Yes.
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
