Re: [RT] function sources

[Leszek Gawron]

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                                      [EMAIL PROTECTED]
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