cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@informatik.tu-darmstadt.de>
Subject Re: [RT] Improving Sitemap and Flowscript
Date Tue, 19 Aug 2003 20:41:51 GMT
Stefano Mazzocchi wrote:
> 
>  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
haul@informatik.tu-darmstadt.de
     fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08


Mime
View raw message