On 11.11.2003 15:48, Geoff Howard wrote:
In fact, I think that flow in some cases needlessly complicates the composition of a pipeline. Now I have to have two pipelines where I used to need one. I have to have one that matches the external request and calls the flow function, and another one for the default result of that pipeline.
I have exactly the same feeling about the flow. I talked about exactly the same with Sylvain in private communication (btw: Did you ignore my last email or didn't you receive it, Sylvain. I sent it on the day you had problems with Anywhere mail to your Apache account - which is probably forwarded to Anywhere :-( ).
I received it, but was so swamped with work and mail problems that I failed to answer...
In German slang I would call the flow "drangepappt". How can this be translated into English: The flow is not integrated into the sitemap very well and makes the sitemap flow somewhat opaque or obfusicated. How must look into the flow to understand what's going on in the sitemap. And if it is so why not integrating the flow script into the sitemap directly? No, I don't want to have Javascript in the sitemap, it's only a bad feeling about that. Especially because of the two-side dependency from sitemap to flow to sitemap.
So far this has felt like needless additional complexity to me (and I think will to others).
To try to make this point a little clearer:
Part of the beauty of the sitemap prior to flow was that you could at a glance see what each request url was triggering. Now, I look at the sitemap, have to locate the flowscript, parse through it for the various sendPage etc. and then back to the sitemap to find where the action really happens. This could perhaps be handled with some best practice naming conventions. Perhaps a practice of passing in the various possible view uris to the flowscript should be considered. I don't know.
Naming conventions is to weak to handle this IMHO.
Exactly. My personal way of doing things is very close to Antonio's: here's a typical sitemap of my flow+woody applications:
<map:pipelines>
<!-- internal URIs -->
<map:pipeline internal-only="true">
<map:match pattern="_view-*.html">
....
</map:match>
</map:pipeline> <!-- public URIs -->
<map:pipeline>
<map:match pattern="edit-*.html">
<map:select type="request-method">
<map:otherwise>
<map:call function="public_{1}"/>
</map:otherwise>
<map:when test="POST">
<map:call continuation="{request-param:continuation-id}"/>
</map:when>
</map:select>
</map:match>
.... other matchers...
</map:pipeline>
</map:pipelines>Several noticeable things:
- internal pipeline is placed first. It makes things faster, as it's checked first for internal request, and ignored for external ones
- "_" prefix for internal URIs avoids most name clashes with external URIs.
- prefixing externally-callable flow functions with the "public_" prefix (or something else) prevents hackers to call non public flow functions
- Distinguishing call/continue with the request method allows to have <form action="">. This is convenient when writing form templates and keeps the browser location bar clean (the address doesn't change)
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
