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>
<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".
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!
Ciao,
-- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
