Hi Marcus,

Those are very good questions. And I don't know the answer. See my response to Vadim about scopes and compiling scripts. We need to partition the scripts by application somehow.

What defines an application in Cocoon. For example, does each get a separate class loader? Is there a relationship to sitemaps?

Regards,

Chris

Marcus Crafter wrote:
Hi All!
        
        One thing I'd like to discuss a little bit more is the relationship
        between individual flow interpreter instances and sub/sitemaps.
        
        Currently, there's one flow interpreter instance created per
        sitemap. So, when operating within the one sitemap everything is
        fine - however it has some implications for larger applications
        that use subsitemaps, etc.
        
        The following:
        
<map:flow language="JavaScript">
  <map:script src="context://WEB-INF/flow.js"/>
</map:flow>

defines some javascript methods that are encapsulated within that sitemap. It would be good if we had a nice way to promote the reuse of any javascript methods that could be reused in a sub/sitemap (I
suppose subsitemaps could just include a common script, but
perhaps there's a more attractive way).

Another area is scope. Global variables managed by cocoon.createSession() are currently only available in the sitemap they're defined in, essentially making them local to that sitemap.

ie. if flow.js defines:

var currentUser = null;


function login()
{
        // assuming valid user
        
        // create a session and store user object
        cocoon.createSession();
        currentUser = new User(username);
        
        // continue processing and send page
}

the currentUser reference is only available in the sitemap the
flow.js was defined in. This means, subsitemaps have no reference
to it in any way - something I would like to find a solution for if possible.

I think this was one area where Ugo (and I) were using manual session manipulation to store cross sitemap data.

Ovidiu and I once talked about the ability to inherit flow data/methods
in subsitemaps, perhaps that's worth investigating a bit more ?

Solving these implications would allow us to use flow to control
an application at a higher level than just in one sitemap.

What do you think ?

Cheers,

Marcus






Reply via email to