cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan <alan-coc...@engrm.com>
Subject Re: [RT] Cocoon Input Model
Date Mon, 01 Mar 2004 15:44:55 GMT
* Daniel Fagerstrom <danielf@nada.kth.se> [2004-03-01 14:54]:
> Bertrand Delacretaz wrote:
> 
> >Le Mercredi, 25 f?v 2004, ? 16:49 Europe/Zurich, Daniel Fagerstrom a 
> >?crit :
> >
> ><snip-plenty-of-good-stuff/>
> >
> >>...But in many cases using SAX based XML as in pipelines is not enough 
> >>we need a data structure i.e. DOM. This leads to flowscript components 
> >>that reads some input format to DOM and from DOM to some output format 
> >>or some store. We also will need flowscript components that go from 
> >>DOM to DOM...
> >
> >
> >Just trying to understand from a practical point of view, does this mean 
> >something like
> >
> ><map:generate type="request"/>
> ><map:transform src="prepare-query-for-user-preferences"/>
> ><map:transform type="sql"/>
> ><map:call function="myFlow()" dom-input="domIn"/>
> >
> >At which point myFlow() is called with a "domIn" variable containing the 
> >current pipeline XML as a DOM?
> >
> >And maybe the opposite:
> ><map:call function="myFlow()" dom-output="domOut"/>
> >meaning that myFlow() is expected to write a DOM structure to domOut for 
> >insertion in the pipeline?
> >
> >-Bertrand
> 
> I meant something a little bit more explicit:
> 
> <map:generate type="request"/>
> <map:transform src="prepare-query-for-user-preferences"/>
> <map:transform type="sql"/>
> <map:store type="xml" dest="xmodule:request-attr:foo"/>
> <map:call function="myFlow()">
>   <map:parameter name="foo" value="{req-attr:foo}"/>
> </map:call/>
> <map:generate src="xmodule:flow-attribute:bar"/>
> ...
> <map:serialize/>
> 
> Following the "to much magic kills the confidence"-principle, I prefer 
> to describe exactly what happens in the sitemap.
> 
> The store component is like a serializer, but the output is directed to 
> a modifiable source given in the dest attribute. And it does not create 
> a return from the sitemap execution as the serializer does, but in the 
> same way as the serializer, the store executes the pipeline ending in 
> the store at setup time. E.g. in the example above the call function 
> will be executed _after_ the pipeline ending in the store component. 
> Most (all?) the current serializers could be used as store components as 
> well if we provide a serializer to store adaptor. The dest attribute 
> should probably be optional, one could consider storing to things that 
> are not described by a modifyable source, e.g. a DB.
> 
> The flow attribute will be set to the return value of the called function.
> 
> function myFlow(foo) {
>   ...
>   var bar = doSomething( foo, ... );
>   return { "bar" : bar };
> }
> 
> Probably another name than call should be used, to differ this use of 
> flowscripts from the one intended for multi page flow. For this kind of 
> use of flowscripts, the sendPage and sendPageAndContinue, functions 
> should be dissabled to protect the user from confusing behaviour.

In your example, is map:store generating a DOM document?

    What would doSomething do? Is this where the document gets
    stored?

I don't see the need for flowscript in this example. There are
    idioms here I don't understand. I'd like to discuss a complete
    example.
    
    <map:match pattern="/request-submit">
      <map:generate type="request"/>
      <map:validate type="relax-ng" src="relax-ng/request.xml"/>
      <map:transform src="reqeust-to-sql-update.xslt"/>
      <map:store type="sql"/>
      <map:generate type="sql" src="query.sql"/>
      <map:transform src="query-to-html.xslt"/>
      <map:serialize type="html"/>
    </map:match>

    <map:match pattern="error-pipline">
      <map:generate type="error"/>
      <map:transform src="error-to-html.xslt"/>
      <map:serialize type="html"/>
    </map:match>
    
-- 
Alan / alan@engrm.com / http://engrm.com/
    aim/yim: alanengrm - icq: 228631855 - msn: alanengrm@hotmail.com

Mime
View raw message