cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: flow: release resources after the view is generated
Date Mon, 14 Jun 2004 21:46:01 GMT
Vadim Gritsenko wrote:

> Sylvain Wallez wrote:
>> Vadim Gritsenko wrote:
>>> What worries me is that sendPageAndWait provides an argument, which 
>>> is reference to the cleanup function. AFAIU, this function should be 
>>> invoked after page is sent. If you take a look at sendPageAndWait, 
>>> it looks like:
>>> FOM_Cocoon.prototype.sendPageAndWait = function(uri, bizData, fun, 
>>> ttl) {
>>>    this.sendPage(uri, bizData,
>>>                  new FOM_WebContinuation(new Continuation(),
>>>                                          this.continuation, ttl));
>>>    if (fun) {
>>>        if (!(fun instanceof Function)) {
>>>            throw "Expected a function instead of: " + fun;
>>>        }
>>>        fun();
>>>    }
>>>    FOM_Cocoon.suicide();
>>> }
>>> So if you provide a function which closes connection, performs other 
>>> cleanup actions, it should be invoked when view is generated. And 
>>> this means, that sendPage returns execution control only when view 
>>> is rendered already. Now, why this does not work or what I'm missing 
>>> here?
>> It may not work if the flowscript is called within an internal 
>> pipeline, since in that case sendPage() only builds the pipeline, but 
>> doesn't execute it.
> Then, does it mean that either (a) function as implemented is 
> misleading/buggy and have to be deprecated/changed, or (b) there is 
> growing need in some change for internal requests handling? hmmm...

That behaviour should work the same for internal and external requests, 
but it seems difficult to change the way internal requests are handled 
(i.e. pipeline building and processing are decoupled).

A solution that comes to mind is to have "pipeline listeners" that would 
be called when Cocoon is done with a pipeline, be it internal or 
external, and had it been actually executed or fetched from the cache.

Now where can we register these listeners? These cannot be fixed 
components as this need varies among requests...

The only valid place I see for this is the object model (requests 
attributes are not suitable as they're attached to the external request 
and thus shared with internal requests). However, that would be the 
first case where it is valid for the application to modify the object 
model. But we can encapsulate this in ObjectModelHelper using 



Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message