cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <>
Subject Re: Original request attributes in internal block servlet call
Date Tue, 21 Nov 2006 17:57:42 GMT
Daniel Fagerstrom schrieb:
> I solved it that way to not need to answer lots of complicated questions 
> about exactly how this should work.
> For request parameters you can in the current solution just resend the 
> parameters that you need as query parameters in the block protocol.

Yup, that's what I am already doing at a different place. But it creates 
long URIs in your sitemap... :-(

> This could be complemented by giving access to the original request 
> parameters. For this case we need a call stack where each block protocol 
> call pushes a new request object, and where all parameter lookup is done 
> through the stack.
> For request attributes the situation is more complicated, we need a call 
> stack where the local attribute context is pushed. Otherwise your block 
> will aways risk that some other block in the call chain happen to use 
> the same parameter name and affect your block. But you probably also 
> need to be able to set the global attribute to communicate state 
> information between blocks. For the Cocoon protocol this is done by 
> having booth a global and a local scope for parameters (see 
> o.a.c.environment.Request). But this solution requires an extension to 
> the standard HttpServletRequest, and I preferred to avoid that. But if 
> we have a need for it we could extend the current design.
> For the rest of the request (and response) object we would need to 
> evaluate what should be available everywhere and what should be specific 
> for the current block call.

I see, it's difficult. My case is attribute-readonly after the listener, 
so it is quite simple. The distinction between global and local 
parameters would be important, since otherwise you'd only had the 
attributes of the previous block call at hand (if there is more than 1 
call to different blocks).

> There should be a simple possibility, just remove the block path 
> property from a managed servlet and then the dispatcher servlet will not 
> use it. And it will still be available as a component and thus possible 
> to connect to and use through the block protocol. Now this will not be 
> usable for the block servlet as it has a getBlockPath method and 
> therefore always will be connected. If we strengthen the condition in 
> the dispatcher servlet to only connect to servlet that has a *non null* 
> block path property, it would be enough to not configure the block path 
> property to make the block servlet internal..

I currently only have the BlockServlet in place. Apart from that, there 
are blocks that contain both external matchers (open to the script 
kiddies) and internal ones, so deciding at the block level would no help 
as everything in that sitemap would be internal. What about extending 
the pipeline parameter internal-only="true" to accept the values 
(true|false|block), where block means visible for blocks but not for 
external requests?

> Would probably work, but as indicated above it should probably be stack 
> based.

Yes, makes sense.

> Thinking further about it, you could take a look at the request scope 
> for Spring managed beans 
> (

> Using that you could put your login information in a request scoped 
> bean, and use that from the different blocks.

Good hint, thanks! I will look into it.


Alexander Klimetschek

View raw message