cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Parameters in request get lost when using servlet: protocol
Date Sun, 08 Apr 2007 12:28:52 GMT
Alexander Klimetschek skrev:
> Rice Yeh schrieb:
>> Thank you for your solution. But I still feel weird for a brand new 
>> request
>> being created for a called block (servlet), at least for a super block
>> (servlet). Having a look at the source code, each new brand request and
>> response are supposed to be stored in its call frame (actually, this 
>> feature
>> is not implemented yet, but api for retrieving these two objects are
>> provided). If such design is intended, why not just treat request and
>> response as part of servlet (block) context. And a way for passing a
>> request's attributes or parameters must be provided. My real opinion 
>> is that
>> request should be pass through all servlets invoked, instead of 
>> creating a
>> new one.
> You are right, as far Cocoon's internal blocks with Sitemap servlets are 
> involved. In that case one can optimize the calls and provide the 
> original context (request, sitemap parameters etc.) to the callee. The 
> only problem you have is how to handle the different parameter levels 
> you have: you might want to have global but sometimes only local 
> parameters, eg. when setting some value in a called block, you don't 
> want it to override a parameter with the same name in the calling block.

Exactly, Alexander and I had a discussion about this some time ago My idea with the current 
implementation was that it is better to implement something minimal and 
extend it based on peoples need than to implement a "faulty" behavior 
that needs to be deprecated later.

Anyway, a better parameter passing method is obviously needed. I 
implemented a special Spring call scope (see for being able 
to store call frame information in a way that works well with Spring. 
While it worked it depended on dynamically compiled proxies, so I 
decided to turn it of as the dynamic proxies didn't work that well 
together with our Maven build.

I also saw that the Spring team worked on a alternative implementation 
that used ordinary Java proxies. This work is finished in the version of 
Spring that we currently use. So we could start to use the "call scope" 
and implement some reasonable parameter passing scheme in terms of that.


View raw message