cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@apache.org>
Subject Re: Flow wishlist :)
Date Tue, 26 Nov 2002 20:23:40 GMT
Hi again Michael and all!

On Friday, Nov 22, 2002, at 04:58 US/Pacific, Michael Melhem wrote:

> Hi everyone,
>
> It was great seeing you all in Ghent!!!! :)

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.

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

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.

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.

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

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.

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

This is something we discussed in the bus while coming back from the 
GetTogether venue, and I fully agree with this change.

> 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. :)

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:

<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 <ovidiu@apache.org>
http://webweavertech.com/ovidiu/weblog/


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


Mime
View raw message