cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: [RT] function sources
Date Tue, 23 Nov 2004 08:23:15 GMT
Miles Elam wrote:
> A while back, Ugo brought up his idea for "A Groovy Kind of Sitemap" 
> which met with some friction.  On the one hand was the camp that felt 
> that the sitemap/flowscript dichotomy was a case of overseparation of 
> concerns.  On the other was the camp that absolutely wanted to keep a 
> general purpose programming language away from the main URI/HTTP 
> decision tree.  At the time, I was firmly in the second camp.
> 
> This is not to say that I now want scripting code embedded in the 
> sitemap.  Far from it.  I still believe that the logic and management 
> issues are absolutely two distinct concerns that warrant a Great Wall of 
> SoC(tm) between them.  However, the feelings of overseparation were not 
> without cause.  Let's face it, it's a major PITA to make two matchers 
> for every scripted source: one for the <map:call /> and one internal 
> pipeline for the flowscript sendPage() output -- and then make sure they 
> all stay in sync.
> 
> So what do you say to function sources?  "Say what," you say?  Pipeline 
> components that take a function call as their source.  Now hold on!  I 
> can feel you slipping away and the cries of FS echoing in the distance. 
>  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>


> 
> Wait!  Wait!  Don't leave yet!  I'm not saying that the "src" attribute 
> a straight call to the flow interpreter as it exists today.  Not at 
> all.  I'm actually suggesting that we've been so caught up in 
> continuations, we've almost forgotten how to write scripts without 
> them.  And why not?  There are three kinds of people in this world: 
> those that don't do web development, those that love continuations and 
> those that don't know what continuations are.  But set aside 
> continuations for now.  They are but one type of scripting contract.
> 
> 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>

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.

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

Mime
View raw message