[vote] finilizing the pending votes on flow [was Re: [RT] Flow/SitemapIntegration]

[Stefano Mazzocchi]

Reinhard Poetz wrote:

Michael Melhem / Stefano Mazzocchi wrote:

<snip>

<map:sitemap>
<map:components>
</map:components>

<map:flow>
  <map:script>
    <src="myflow.js">
  </map:script>
  <map:flowmap>
    <map:map pattern="login/"  flow="login"/>
    <map:map type="regexp" pattern="register*/"

flow="registerUser"/>

    <map:map pattern="logout/" flow="logout"/>
  </map:flowmap>
</map:flow>

<map:pipelines>
  ...
</map:pipelines>
</map:sitemap>

We could define a flow mapping as a "matching" between a flow function
and its corresponding entry point pattern (which could be an URI
or whatever)

True.

We could use the <map:match> directly withing the flowmap to implement
this, but this would not force the user to call a flow method and would
not allow for the compact easy-to-read syntax above.

But I'm pretty sure that people *will* want to extend that and will
complain about the fact that <map> and <match> do, in fact, the same
thing, but with different semantics and this won't please people (nor
please my sense of semantic elegance, to tell you the truth)

A map:map = map:match + map:call

Im not against using <map:match> here within the flowmap...but
I do have to ask wouldnt it suggest to the user (incorrectly) that this
is another a "pipeline" where they can assemble anything they like?

I don't think so because the flow related stuff is outside of
<map:pipelines>...</map:pipelines>. And a second arguement: the sitemap
interpreter will not allow such constructs.

Therefore I would use following XML to declare the mappings to flow scripts.
...
</map:components>
<map:flow>
   <map:scripts language="JavaScript">
       <map:script src="scripts.js"/>
   </map:scripts>
   <map:flowmap>
      <map:match pattern="xxx">
         <map:flow call-function="xxx()"/>
      </map>
      <map:match type="request-parameter" pattern="cont-id">
         <map:flow continue-with="{1}"/>
      </map:match>
   </map:flowmap>
</map:flow>
<map:pipelines>
...

This would have following advantages:
 - reuse of the matchers
 - easier for existing cocoon users to understand the mapping
   between uri/request-parameter/what-ever  <---> flow
 - possible to submit parameters to the matcher AND to the function
 - clear separation between pipelines and flows

and
 - (as already mentioned in this thread): the <map:flow>-part should match
   before the <map:pipelines> part

... disclaimer:
I know that element/attribute names are important but my point in this mail
is the structure - so please don't discuss why I named elements this ;-)

Perhaps at the implementation level <map:match> and <map:map> are
similar, but conceptually they are different.  Using <map:map> will
encourage the user to think of the mapping as a single atomic
instruction and not try and "tinker" with other
components (routing or otherwise). Hmmm....but im still in two minds
about this. :)

What do you mean exactly?
What I *really* need is a way to redirect to a URI which is mapped to a
flowscript - which is currently possible.

If we use <map:map> component (as suggested above), the question then
becomes, how do we get the <map:map> component to match (URIs in
the above case)?

Is there a reason why we wouldnt use (under the hood) the
already existing matcher components to the matching here?.

No technical reason (that I can think of) but it's a purely

semantical one.

Granted that it makes sense to move the flow hooks from the pipeline, I
think that we should reuse semantics where it makes sense, because
people already made an effort to learn it and in that case we reduce
their need to learn new stuff.

Exactly!

Thoughts?

What about issues like backwards compatibility. If we were to get the
the go ahead form the list to implement this, would we still allow
flow-hooks within the pipelines sections as is the case now - for the
sake of backward compatibility??

I think there should be a *final* vote about the semantics without
considering backward compatibilty:

I find myself resonating with your vision entirely!

 - should "flow-hooks within the pipelines" be removed?

No, at least for now. I would say let's do it and see what happens.

 - names of the flow elements (scripts, call-function, continue)

I think we settled down on that issue, didn't we?

 - allowing the cocoon protocol calling scripts?
  (I'm in favor of it because this could become a *really* cool feature!)

Yes, I'm definately +1 on this after some careful thinking.

Let me add:

- make a new method that allows the flow to call a pipeline and pass a different output stream. This will allow to use pipelines as tools to serialize things, say, to disk or to other means.

What do you think?

--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]