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.
The advantage of the servlet protocol internally is that you can mount any
servlet as a block, not only cocoon's sitemap servlet. We for example have
mounted the Solr servlets (for indexing and searching with lucene) as normal
blocks. This is a nice feature that allows you to manage your complex web
application solely with Cocoon and Spring.
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
