Carsten Ziegeler wrote:
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.
Cool.
<snip/>
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.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.
Sure.
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 "cocoon:attribute-scope=local|global".
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 compatibility.
<snip/>
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 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.
What do you mean by "dynamics"? Isn't it dynamic enough if any component in the processing chain can register a listener?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
