On Fri, Nov 22, 2002 at 10:08:58AM -0800, Stefano Mazzocchi wrote:
> Michael Melhem wrote:
...
> >
> >
> >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)
Yes, the flow logic needs to be factored 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.
>
> 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.
Well, there is a use-case for having *global* flow script objects
available to pipelines which are not invoked via sendPage*() methods.
Consider a login flow which creates a global flowscript User object and then
performs a cocoon.createSession() to make this object available as long
as the session exists.
Other match-pipelines (which could be invoked directly) might also need to access
the User Object (say to print the name of the currently logged in user
or something).
...
>
> >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?)
This would allow sitemap flow functions to transparently exhibit different
behavior depending on the currently loaded flow controller (assuming that
it implements the function). Im not sure if you would call this a type
of polymorphism.
Do we really need it, is a good Question! Granted it does sound like FS,
but Im still ambivalent about this.
And Yes, Torsten Curdt idea to use the the cocoon protocol:
<map:flow language="JavaScript">
<map:script src="cocoon://something/prefs.js"/>
</map:flow>
Would be one way to provide for dynamic flow loading etc.
Regards,
Michael Melhem
>
> >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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
