Return-Path: 
 <cocoon-dev-return-28485-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 21890 invoked by uid 500); 20 Jun 2002 03:32:04 -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 21879 invoked from network); 20 Jun 2002 03:32:04 -0000
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Wed, 19 Jun 2002 20:32:05 -0700
Subject: Re: [RT] Flowmaps
From: Ovidiu Predescu <ovidiu@apache.org>
To: <cocoon-dev@xml.apache.org>
Message-ID: <B9369AC5.637B%ovidiu@apache.org>
In-Reply-To: <026401c217ee$eee55f20$0a00a8c0@vgritsenkopc>
Mime-version: 1.0
X-url: http://www.geocities.com/SilliconValley/Monitor/7464/
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Hi Vadim,

On 6/19/02 5:10 PM, "Vadim Gritsenko" <vadim.gritsenko@verizon.net> wrote:

>> From: Ovidiu Predescu [mailto:ovidiu@apache.org]
> 
> <snip/>
> 
>>>> 8. Vadim's idea about making the syntax easier.
>>>> 
>>>> I think the idea of having something as simple as:
>>>> 
>>>> <map:match pattern="calc/*">
>>>>   <map:flow method="calculator" continuation="{1}" />
>>>> </map:match>
>>>> 
>>>> makes a lot of sense. Using different matchers, the continuation id
> can be
>>>> extracted from the request parameters, cookies, you name it. The
> only
>>>> problem with it is that is a bit inflexible in terms of the URI
> design. If
>>>> I'd like to have calc/kont/*, there's no easy way to specify it.
>>> 
>>> <map:match pattern="calc/kont/*">
>>> 
>>> Did I miss somehting?
>> 
>> How do you extract the continuation id if it's embedded in a request
>> parameter?
> 
> You asked for calc/kont/* - and that's very easy to achieve as shown
> above. If you want to hide continuation ID to request parameter, that's
> also very easy with existing request parameter matcher:
> 
> <map:match pattern="calc">
> <map:match type="parameter" pattern="cont-id-param">
>   <map:flow continuation="{1}" /> [here we could omit method=""]
> </map:match>
> <map:flow method="calculator"/> [here we can omit continuation=""]
> </map:match>
> 
> 
> I poked around with continuation sample today... Seems this is even
> possible right now, with your current code. The only difference is that
> instead of one map operator you have to use two different ones (and one
> of them is (over) overloaded map:call):
> 
> <map:match pattern="calc">
> <map:match type="parameter" pattern="cont-id-param">
>   <map:continue with="{1}"/>
> </map:match>
> <map:call function="calculator"/>
> </map:match>
> 
> 
> Difference is only in syntax.

Thanks a lot for the analysis, it's great!

To conclude, the simplest form would be:

<map:match pattern="calc/*">
  <map:flow function="calculator" continuation="{1}"/>
</map:match>

If more control is needed, we can use <map:flow> with different attributes,
like below:

<!-- starts script because continuation is empty (or "continuation"
     attribute is missing -->
<map:match pattern="calc/">
  <map:flow function="calculator"/>
</map:match>

<!-- continues script because "function" is missing -->
<map:match pattern="calc/kont/*">
  <map:flow continuation="{1}" />
</map:match>

Or we can have the continuation id passed as a request parameter, like
below:

<map:match pattern="calc">
  <map:match type="parameter" pattern="cont-id-param">
    <map:flow continuation="{1}"/>
  </map:match>
  <map:flow function="calculator"/>
</map:match>

We can use either "function" or "method", I don't have any preference.
"function" however is more appropriate for JavaScript where what is actually
invoked are functions, not methods.

The change to use the above API involves only the treeprocessor portion of
Cocoon, and some calls to the flow API. The change could be modeled on the
current implementation, so it should be fairly straightforward. Any
volunteers to implement this?


Best regards,
-- 
Ovidiu Predescu <ovidiu@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org