Hi again Michael and all! On Friday, Nov 22, 2002, at 04:58 US/Pacific, Michael Melhem wrote:
Yes, it was a lot of fun! Sorry for being late with my replies, I'm slowly catching up with emails, not only on cocoon-dev. And just when I'm going to finish doing it, the Thanksgiving holiday comes up tomorrow ;) I'll be again gone away from email until Sunday.Hi everyone, It was great seeing you all in Ghent!!!! :)
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.On Sat, 16 Nov 2002, Sylvain Wallez wrote:I agree that flow should be considered a "first class Cocoon citezen"
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.
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.
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.
There are two issues which are mixed here. The first is whether global variables of a flow script should be made available to subsitemap, and the second is whether flow scripts need to be inherited in subsitemaps.Yes, a method is needed to regulate flow scope with regard to mounted sub
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>.
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
The issue is quite complex, because of the way flow is implemented. If a subsitemap decides to extend the flow inherited from its parent, sharing global variables becomes very difficult. As I said earlier, the values of global variables is maintained in different Scriptable objects, one in the parent and the other in the child sitemap. Merging the two can be a difficult.
I don't have time to get into a lot of detail, but we have the following cases I came up with after much thinking:
- parent sitemap defines a flow script, child sitemap defines none and inherits the parent's flow. The child uses the parent Interpreter object directly. This can pose problems when multiple children sitemap scripts modify global variables in the parent.
- parent sitemap defines a flow script, child sitemap defines none; the implementation creates a copy of its parent Interpreter instance. This makes global variables in parent and child separated. I think we can arrange with Rhino to have read-only access to global variables being taken out of the parent flow script, but changes to them being applied in the child flow. Not sure about it however.
- parent sitemap defines a flow script, child sitemap extends it with new scripts. The child sitemap now has its own Interpreter object, with its own scope for global variables. Changes in the global variables of a child are now separated from the parent.
As you see the issues are quite complex, so I'd like to postpone this discussion after we have more experience programming with the flow. For now I'd like to simply make available the global variables to the sitemap components, which is a very simple thing to do.
Other Issues and Ideas:This is something we discussed in the bus while coming back from the GetTogether venue, and I fully agree with this change.
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.Um, how about if you put the flow for a different role in a different JavaScript function, and call that instead? It could be as simple as this:
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. :)
<map:match ...>
<map:call function="dispatch"/>
</map:match>
function dispatch()
{
var user = login();
if (user.isReader())
flowForReader();
else if (user.isAdmin())
flowForAdmin();
}
function login()
{
var user;
...
return user;
}
function flowForReader()
{
...
}
function flowForAdmin()
{
...
}
This way there's no need for extending the sitemap semantics or doing any hack like this. Just take advantage of the full power provided to you by a programming language.
Regards,
--
Ovidiu Predescu <[EMAIL PROTECTED]>
http://webweavertech.com/ovidiu/weblog/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
