cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] The API for the request object
Date Tue, 06 Jul 2004 12:45:03 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>>Big +1 , but what about naming it getSitemapPath() to mimic 
>Hm, sounds better to me, but we have used "prefix" everywhere else.
>Ok, I like your suggestion more.



>>I was recently looking at flowscript within coplets, and thought this scope should
better be defined by the surrounding caller, i.e. by a coplet parameter. That way, the request
providing coplet contents doesn't have to care whether it's used withing a coplet or not,
which can be especially useful to "portalize" application modules not initially designed with
these problems in mind.
>>Of course, there are cases where we need to mix both kind of scopes, and the coplet
attribute could therefore be used to define the default scope if not specified.
>I'm not sure if I understand what you mean :) Sure, if you're using the portal with coplets
you run very quick into this problem, but you might hit it without the portal (when doing
simple aggregation) as well.


>In that case, it would be difficult to define the scope by the caller.

I'm more and more thinking we should standardize the use of "cocoon:*" 
request parameters for "cocoon:" urls. We already talked about 
"cocoon:handle-errors=true|false", and here comes 

This is a simple (and IMO elegant) way for the caller to specify how the 
internal request environment should behave.

>Now, in general I would like to have "request" as the default and not "global", but that's
unfortunately incompatible. With "request" as the default, you develop your things standalone
and just if you need "communication" with other parts you use "global".

This totally makes sense. But just like you, I have some fears about 


>>What about adding a list of ProcessingListeners to the object model, which can be
augmented by the various components that participate in request handling, and is called at
particular places such as:
>>- processing start (such listeners must be registered in the xconf),
>>- sitemap mount,
>>- end of pipeline building,
>>- start of pipeline execution (differs from the previous one as it may not be called
if the result is cached)
>>- end of pipeline execution
>>- end of processing
>>That would allow e.g. a flowscript to register a listener that closes a hibernate
session once the processing is terminated, thus allowing the same session to be used in the
>Yes, something like that. I would like to have some dynamics in the listener concept,
so I can add at run time a listener. This would solve the problem as well.

What do you mean by "dynamics"? Isn't it dynamic enough if any component 
in the processing chain can register a listener?


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

View raw message