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