cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Makes flow script the sitemap ugly?
Date Tue, 11 Nov 2003 22:24:20 GMT
Joerg Heinicke wrote:

> 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



Mime
View raw message