cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Elam <>
Subject [RT] function sources
Date Tue, 23 Nov 2004 00:44:24 GMT
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"/>

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;

And why not?  Because it's a dynamic/scripted source?  Can you 
guarantee that src="http://someserver/foo" is not completely dynamic 
and backed by a script?  The contract strength is the same in that the 
source must follow certain expectations for the pipeline up to this 
point.  "src" is an injection of data.  Nothing more.  Nothing less.  
So yes, the object data could indeed be a content source and nicely fit 
into the "src" attribute paradigm.

Logic is kept at arm's length from the sitemap AND there are no blind 
"where's in coming out" logic paths.

So the following questions remain:
1. Does this ease overseparation concerns somewhat?
2. Does this avoid gratuitous FS-syndrome?
3. How easy would it be to wire this into the existing codebase (eg. 
4. Could the same flow engine be used but with a different set of 
default objects/interfaces?
5. Am I completely off my rocker?

I think the answers to 1-3 are "yes".  I'm not familiar enough with 4 
to make any comment.  5 I'll leave as an exercise for the reader.

- Miles Elam

View raw message