Re: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)

[Stefano Mazzocchi]

On 13 Nov 2003, at 00:20, Andrzej Jan Taramina wrote:

Ugo suggested:

  <map:match pattern="*/profile/edit">
    <map:call function="dumpData"/>
  </map:match>

  <map:match pattern="view">
    <map:generate src="cocoon://generate"/>
    <map:transform src="homePage.xsl"/>
    <map:serialize/>
  </map:match>

function dumpData() {
   dumpUserData();
   dumpOrderData();
   dumpNewsItems();
   cocoon.sendPage("view");
}

The main problem I have with this approach is that without looking at the
script code, there is no easy way of telling that the first match will end up
calling the second one and so the flow of the application becomes more
opaque...and thus harder to understand and maintain.

True. [see the other thread on flow polluting sitemap readability]

I like Tim's approach much better....where everything is in one place and the
high level flow of control is quite clear and transparent.

nah, it follows the same patter of action: it's cool when it's nice and clean and simple... but the more complex it becomes the more it blows in your face, we must be more creative to solve this issue.

also glad to see that I am not the only one that has used this paradigm.
<grins>

yeah, sounds like "millions of outlook users can't be wrong" as an add campaign ;-)

An action that will call a flowscript for you without the sendPage
restriction would seem to be a reasonable alternative, in which case Tony's
code then looks like:

<map:match action="*/profile/edit">
        <map:act type="FlowscriptAction"  function="dumpUserData">
                <map:call function="dumpOrderData"/>
                <map:call function="dumpNewsItems"/>
                <map:generate src="cocoon://generate"/>
                <map:transform src="homePage.xsl"/>
                <map:serialize/>
        </map:act>
        ... error stuff can go here...
</map:match>

you all the function twice? c'mon.

Which I like even better...since you have the ability to branch the flow
based on success/failure of the action. You could also allow parameters as
input to the function by doing something like:

<map:act type="FlowscriptAction"  function="dumpUserData">
        <map:parameter value="xxx"/> <!-- name attribute could be ignored -->
        <map:parameter value="yyy"/>
     .... as before

here you go, told you.

where the method signature of dumpUserData would look like

function dumpUserData( xValue, yValue ) {....}

Clean...crisp...understandable...functional....and doesn't clutter the
architecture.

bah, we have different tastes.

+1 from me for the FlowscriptAction approach and soon too!

I think the selector idea is much better, let's work on that.

--
Stefano.

smime.p7s
Description: S/MIME cryptographic signature