cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Improving Sitemap and Flowscript
Date Fri, 22 Aug 2003 17:51:26 GMT

On Wednesday, Aug 20, 2003, at 20:15 Europe/Rome, Gianugo Rabellino 

> 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... ;-)

Really? any pointer? (I'm not being sarcastic, but curious... if I 
judged FS something that I later ended up proposing, there is something 
wrong in my FS meter ;-)

>>  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.

Yes, I think this is a better solution.

>>  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 couldn't come up with anything that required more than that.

> 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.

Why so, can you elaborate? maybe with a specific example? scenarios 
help the design.

>>   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>
> <match pattern="myapp/protected">
>    <call function="main"/>
> </match>
> <match pattern="myapp/login">
>    <call function="login"/>
> </match>
> with "checklogin" being just a switchboard function redirecting to 
> either "myapp/protected" or "myapp/login".

No, interception allows you to remove and compose aspects without 
requiring to rewrite any part of the code (only the section that 
identifies the intercepting patterns to apply).

I agree that actions, in this sense, are more orthogonal. Will reply to 
Christian in more detail on this.

> 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!

Keep in mind that interception is not AOP, only one of the possible way 
to decompose a program into orthogonal layers that can be applied and 
removed. To me, it feels more like SoC at intra-function scripting 
level than anything else.


View raw message