On Wednesday, Aug 20, 2003, at 20:15 Europe/Rome, Gianugo Rabellino wrote:
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;
Ok
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.
-- Stefano.
