cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [RT] The API for the request object
Date Tue, 06 Jul 2004 10:30:16 GMT
Sylvain Wallez wrote:
> Big +1 , but what about naming it getSitemapPath() to mimic 
> HttpServletRequest.getServletPath()?
Hm, sounds better to me, but we have used "prefix" everywhere else.
Ok, I like your suggestion more.

> >Attributes
> >----------
> >
> >We have a similar problem with attributes on the request object.
> >Currently the attributes are shared between external and internal 
> >requests, making them "global".
> >So, an internal request can overwrite attributes of the external 
> >request and of other internal requests. This can lead to serious 
> >problems especially if you have several internal requests at 
> the same 
> >time using the same attribute - or if you want to process internal 
> >requests in parallel.
> >
> >Again, because of compatibility, we can't change this behaviour.
> >But we can extend it. Currently we have these methods for attributes 
> >that work on global attributes:
> >
> >setAttribute(String, Object)
> >getAttribute(String)
> >getAttributeNames()
> >removeAttribute(String)
> >
> >We could add another set of methods that take an additional scope 
> >parameter which is either "global" or "request" (like the 
> portlet api 
> >does for session attributes):
> >
> >setAttribute(String, Object, int scope) getAttribute(String, 
> int scope) 
> >getAttributeNames(int scope) removeAttribute(String, int scope)
> >
> >Our old method (without the scope) are simply an alias for the new 
> >methods with the scope "global".
> >  
> >
> 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.
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".

> >Cleanup of Attributes
> >---------------------
> >Currently there is no nice way to cleanup some objects when the 
> >processing is finished. This only works for components that are 
> >pooled/recycled but not for data objects.
> >
> >With 2.1.5 you could do this by adding a custom listener to 
> the Cocoon 
> >object and clean up. But this approach is not so nice as you 
> can only 
> >add one listener and you have to do it manually. And the listener is 
> >not invoked for internal requests.
> >  
> >
> Uh? Didn't knew about this feature!
It's very new and does not cover many use cases :( I think it would
have been better if we had invested more time into thinking about
how to add these feature.

> <SNIP/>
> 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 view.
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.


View raw message