Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: error (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <41A2F373.3080501@mobilebox.pl>
References: <D2AA5324-3CE8-11D9-B496-000393539234@pcextremist.com>
 <41A2F373.3080501@mobilebox.pl>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <6C459A54-3D78-11D9-B496-000393539234@pcextremist.com>
Content-Transfer-Encoding: 7bit
From: Miles Elam <miles@pcextremist.com>
Subject: Re: [RT] function sources
Date: Tue, 23 Nov 2004 09:52:20 -0800
To: dev@cocoon.apache.org

On Nov 23, 2004, at 12:23 AM, Leszek Gawron wrote:

> Miles Elam wrote:
>> Try this on for size:
>> <map:match type="regexp" pattern="document-(\d+)">
>>   <map:generate type="file" src="mytemplate.jx"/>
>>   <map:transform type="jxtemplatetransformer" src="getDocument({1})"/>
>>   <map:serialize type="xml"/>
>> </map:match>
> Hmm what did you mean by that? JXTT is not parametrizable with src so 
> did you mean:
>
> <map:match type="regexp" pattern="document-(\d+)">
>   <map:generate type="jx" src="getDocument({1})"/>
>   <map:serialize type="xml"/>
> </map:match>

No, my example was a hypothetical, not based on current code.

>> What if there was an alternate scripting contract?  One that instead 
>> of requiring a sendPage, sendPageAndWait or redirect-to call, 
>> requires that *none* of these exist in the code path and that an 
>> object context is returned like the parameter of the sendPage* 
>> functions.
>> function getDocument (docid) {
>>   var myObject;
>>   //
>>   // *** hypothetical Hibernate call with a lookup via docid,
>>   // assignment to myObject and other sundry details ***
>>   //
>>   return myObject;
>> }
> something like this was already possible when it was not required for 
> the flowscript function to invoke sendPage or sendPageAndWait. Then 
> you could do something like:
>
> <map:match pattern="someUri">
>   <map:call function="myFunction">
>     <!-- the function stores result in request attribute -->
>     <map:generate src="request-attr:mydata" type="jx"/>
>     <map:serialize type="xml"/>
>   </map:call>
> </map:match>

No, that's not what I mean.  That is subverting an existing contract.  
I don't want to alter the map:call syntax at all.  It is great the way 
it is.  I'm talking about establishing a new scripting contract -- a 
separate contract -- one that specifically forbids the use of 
sendPage*() and redirect-to().

> This is like the function was an action really (which I found kind of 
> nice for fasst scripting actions - I usually used XSPs for that one 
> but the startup time was killing me, syntax also).
>
> Now this call wouldn't succeed. Every call to a function must result 
> with sendPage.

With the current flowscript, yes.  Once again, talking about a 
different contract.  I'm talking about finding some middle ground 
between a continuation-based flow model and the piecemeal 
sitemap/action model.  In other words, the ease of writing flow -- 
which let's face it, is much more convenient than writing an action -- 
with a reduction of scope where redirection is not possible, only data 
gathering.

I proposed the "src" attribute as a data vector because (a) that is an 
accepted data source input point, (b) a sitemap component would have to 
be rewritten anyway to take advantage, mitigating the action 
alternative, and (c) it's easier for users to conceptualize while 
simultaneously respecting SoC.  For a quick "get-in-get-out" problem, 
this would work.  Once they need to go to multiple pages and alternate 
outputs, they graduate to map:call and the continuation model; They 
switch to a different contract that fits their needs.

This would also serve as an easy introductory alternative to XSPs.  Not 
only does it respect SoC better than XSPs (which don't respect it at 
all), but the code reuse in flow would be a boon as well.  Continuation 
code could call the simple data gathering function they've already 
written.  The developer simply cannot write a simple data gathering 
function that calls continuation code.  It's a fail-fast model where 
the developer knows very quickly that they're doing something wrong.  
It's also a more natural transition from the simple publishing model to 
the interactive data processing model.

Function sources are a very specific, directed option unlike the use of 
an action.  With an action -- let's say an action was made to make 
non-exiting/non-continuation function calls -- you are talking about 
more complexity and far more side effects since the flow changes would 
still need to be made, a sitemap component would still need to be 
retrofitted, the sitemap would be harder to read, the sitemap syntax 
wouldn't necessarily tell you which components would be consuming the 
action's info, etc.  Also, what is the use case for data injection that 
spans multiple components but only injects the same content?  The 
actions I've found the most useful are the resource-exists and the 
authentication/authorization actions.  These dynamically alter the 
structure of the pipeline.  The actions which have historically 
provided information have for the most part been subsumed into input 
modules.  Why?  My take on it was that use of actions for content 
gathering muddied the sitemap semantics and required all sorts of 
{../../../1} configuration headaches.

<map:transform type="foo" src="getBar({1})"/>

Simple, descriptive, and limited in scope.  But the exact syntax is 
IMHO irrelevant.  It's the concept I'm more concerned about.  If it 
were a comma separated list like

<map:transform type="foo" src="getBar,{1}"/>

or considered another input source

<map:transform type="foo" src="func://getBar/{1}"/>

or parameters were specific to the transformer

<map:transform type="foo" src="getBar">
   <map:param name="src-param1" value="{1}"/>
</map:transform>

...although I can't say I cared for the last two.  The second to last 
is ripe for URI abuse.  The only major issue with the first two is that 
commas become reserved characters.

- Miles Elam