cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: [RT] Improving Sitemap and Flowscript
Date Wed, 20 Aug 2003 18:15:35 GMT
Looks like I missed some serious fun during these vacations... time to 
catch up!

Stefano Mazzocchi wrote:
>  Virtual Pipeline Components
>  ---------------------------

Love the idea. Even because it was me suggesting something like that a 
couple of years ago and being blamed of FS... ;-)

>  Moving Sitemap components into cocoon.xconf
>  -------------------------------------------
> the default sitemap is too verbose and this scares people away. I would 
> like to move the default sitemap component definitions into the 
> cocoon.xconf.

Correct analysis, but I'm not sure about the solution: I still think 
that components belong to the sitemap, and I tend to agree with Jay's 
suggestion to provide a base.xmap with component declarations and a 
sitemap.xmap with just pipelines.

>  Pluggable Request Factories
>  ---------------------------
> Cocoon needs a simple way to deal with complex HTTP usages, such as 
> binary uploading, XML-RPC, WebDAV or SOAP.
> After a lot of discussion with Sylvain and input from many other people, 
> I propose the introduction of a new sitemap element named 
> "map:adaptRequest" that works by adapting the Request object into a more 
> specific object that will parse the request and provide API-level access 
> to the request.

Hmmm... need serious thinking here, a drawing board and some coffee. But 
here are a couple of eurocents:

1. I don't like the "adaptRequest" name, it's a bit inconsistent with 
other sitemap semantics: I'd go for "adapt-request" instead;

2. Are you sure that adapting the request is enough? I'd say that the 
different use cases you're pointing out require a bit more then just the 
request object: I'd say that the whole environment might need a 
particular treatment in most cases.

>   Interception in Flowscript
>  ----------------------------
> Adding interception mechanism to the flowscript requires three changes, 
> two in the FOM, one (more important!) in the javascript syntax:

Very interesting, even if, as Christian points out correctly, the AAA 
sample of yours might be done too using an action. Or even (hacky?) with 
nested flow calls:

<match pattern="myapp">
    <call function="checklogin"/>

<match pattern="myapp/protected">
    <call function="main"/>

<match pattern="myapp/login">
    <call function="login"/>

with "checklogin" being just a switchboard function redirecting to 
either "myapp/protected" or "myapp/login".

But interception is way more than this, so I'd just love to have a bit 
of AOP in Cocoon flow. However, this brings me back to my pet peeve: 
adding such functionality on Rhino screams for a merge of our patches 
before even thinking of it. AOP in Javascript... how cool!


Gianugo Rabellino
Pro-netics s.r.l. -
Orixo, the XML business alliance -
     (Now blogging at:

View raw message