Return-Path: 
 <cocoon-dev-return-44009-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 55472 invoked by uid 500); 24 Jun 2003 09:13:49 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 55459 invoked from network); 24 Jun 2003 09:13:48 -0000
Received: from anchor-post-39.mail.demon.net (194.217.242.80)
  by daedalus.apache.org with SMTP; 24 Jun 2003 09:13:48 -0000
Received: from media.demon.co.uk ([80.177.14.141])
	by anchor-post-39.mail.demon.net with esmtp (Exim 3.36 #2)
	id 19UjsF-0007ew-0U
	for cocoon-dev@xml.apache.org; Tue, 24 Jun 2003 10:13:59 +0100
Date: Tue, 24 Jun 2003 10:13:58 +0100
Subject: Re: FOM, views, and input modules
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Jeremy Quinn <jeremy@media.demon.co.uk>
To: cocoon-dev@xml.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3EF67AB7.9020508@verizon.net>
Message-Id: <30015654-A624-11D7-AFAD-0003935AD2EE@media.demon.co.uk>
X-Mailer: Apple Mail (2.552)
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


On Monday, June 23, 2003, at 04:57 AM, Christopher Oliver wrote:

> I modified the FOM implementation in the scratchpad to make the FOM 
> available to the view layer, thinking that the view author also should 
> see the FOM (See FOM_JavaScriptFlowHelper.java), rather than the raw 
> Request, Response, etc. Do others agree with this?
>
> I also modified the GarbageGenerator to use the FOM.
>
> So because of the FOM you can't do this in a flow script anymore:
>
>   cocoon.request.sitemapURI
>
> likewise in a Garbage view template you can no longer do this:
>
>    <page whatever="{$request/sitemapURI}">
>
> in both cases because the FOM doesn't expose the "sitemapURI" property 
> of the Request.
>
> However the input modules give full access to the original Java 
> Request object, so in the sitemap you can still do this:
>
>    <map:call function="whatever">
>        <map:parameter name="whatever" value="{request:sitemapURI}"/>
>
> and pass it as a parameter to your flowscript, bypassing the FOM (!)
>
> This seems inconsistent to me. What do others think?

I like to have access to the URI of the request from within the 
flowscript.
Specially because I put my Continuation in a request param and match it 
with the RequestParam Matcher (I hate seeing that in the URL).
So passing the URI from the sitemap is not so easy in my case ....

regards Jeremy