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
http://marc.info/?t=116412357400001&r=1&w=2. 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
http://marc.info/?l=xml-cocoon-dev&m=116593632301167&w=2) 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.
/Daniel
