Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: domain of ap-cocoon-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@cocoon.apache.org
From: Alexander Klimetschek <alexander.klimetschek@mindquarry.com>
Subject: Re: Parameters in request get lost when using servlet: protocol
Date: Tue, 03 Apr 2007 10:26:55 +0200
Lines: 33
Message-ID: <eut34g$2bj$1@sea.gmane.org>
References: <47f71d940704012335ic080521s177e9a03d8b512e1@mail.gmail.com>
	 <euqte0$ktg$1@sea.gmane.org>
 <47f71d940704022130s68872715o4ffaf28f66450efa@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
In-Reply-To: <47f71d940704022130s68872715o4ffaf28f66450efa@mail.gmail.com>
Sender: news <news@sea.gmane.org>

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