Virtual Pipeline Components ---------------------------
<snip what="suggestions I agree with"/>
I'm all in favour of this since the topic came up first. Unfortunatly, I haven't found the time investigating an implementation but I believe this should be straight forward.
Although we're not (yet) discussing implementation details, I would like to suggest to wrap those pipeline fragments as Avalon components. I believe this will become handy with blocks as we only need to expose components from a block....
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.
Note that with blocks, the definitions of those components will be in the block.xconf as well and this will be aggregated by the block manager.
We had this already at some time. Cutting the complexity is good. Perhaps we should follow the idea of splitting cocoon.xconf and root sitemap.xmap into two files each, one for the defaults and one (empty) for customization.
Pluggable Request Factories ---------------------------
<snip/>
OK
Interception in Flowscript ----------------------------
While writing flowscripts, you realize how many things can be applied to many of the various flowscript functions that are called by the sitemap. In Linotype, I ended up using the ability that javascript gives you of using functions as native objects and then invoquing them by passing a modified argument vector.
It came to me that what I did with linotype was a really-poor-man interception mechanism. Interception is the ability to "intercept" a method call and execute some code before or after the execution of the intercepted method.
Interception is the simplest form of the aspect orientation.
Adding interception mechanism to the flowscript requires three changes, two in the FOM, one (more important!) in the javascript syntax:
1) the addition of a function call to the "cocoon" object, which indicates that intercepting function calls should be imported.
cocoon.apply("blah.js");
where "blah.js" contains the intercepting functions.
2) the addition of a function call to context that continues the intercepted invocation:
... continueExecution(arguments); ...
3) the introduction of wildcars for function names.
function get*() { ... }
the above seems rather accademic, so allow me to write an example where the use of aspect-oriented flowscript would shine.
Something that can be modelled very well as an aspect is authentication/authorization (aka login) because it's not something that is part of the webapp (at least, it shouldn't be!) but it's something that is "wrapped" around it to allow people to access it without the proper authorization.
Here I like to disagree, sort of. While I agree that authentication is a good use case for AOP, I don't come to the same conclusion. In fact, by using an action to protect a complete URI space very much the same can be achieved. I know, actions are not liked by everyone, but this is one of the best applications for them.
So, please provide a more convincing use case for the introduction of AOP in Cocoon ;-)
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08