You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2004/03/01 15:48:52 UTC
Re: [RT] Cocoon Input Model
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.
/Daniel
Re: [RT] Cocoon Input Model
Posted by Alan <al...@engrm.com>.
* Daniel Fagerstrom <da...@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
Re: [RT] Cocoon Input Model
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Lundi, 1 mars 2004, à 15:48 Europe/Zurich, Daniel Fagerstrom a écrit
:
> ...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.
Thanks for the clarification, and I see your point about being explicit.
> ...For this kind of use of flowscripts, the sendPage and
> sendPageAndContinue, functions should be dissabled to protect the user
> from confusing behaviour.
Makes sense. But couldn't the second generator
> <map:generate src="xmodule:flow-attribute:bar"/>
be replaced by the flow function calling sendPage() to another
pipeline, to cause less changes to the existing sitemap idioms?
-Bertrand