Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: Fri, 22 Aug 2003 20:59:03 +0200
Subject: Re: [RT] Improving Sitemap and Flowscript
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Stefano Mazzocchi <stefano@apache.org>
To: dev@cocoon.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3F428B8F.7080901@informatik.tu-darmstadt.de>
Message-Id: <B2B867A8-D4D2-11D7-9393-000393D2CB02@apache.org>


On Tuesday, Aug 19, 2003, at 22:41 Europe/Rome, Christian Haul wrote:

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

true

> I know, actions are not liked by everyone, but this is one of the best 
> applications for them.

are you suggesting we don't think about adding interception in flow 
because otherwise this would kill the only place where actions have a 
reason to exist?

> So, please provide a more convincing use case for the introduction of 
> AOP in Cocoon ;-)

Actions can be used as interceptors. It's not their only ability, but 
yes, it's possible and good actions do perform this way.

So, any use case that requires action-based interception, will work as 
nicely with flow interception.

What would we gain?

1) action-based interception is a concern of the flow layer, not of the 
pipeline definition. i will never stop saying this, but actions should 
not exist in the sitemap realm, since they mix concerns.

2) actions have a terribly poor error handling capability, even when 
used as interceptors, flow-based interception keeps all the 
functionality available at the flow level.

3) actions are hardcoded in the sitemap pipelines definitions. 
flow-based interception will allow to wrap existing code without 
needing to modify it or it will be possible to "remove" or modify 
interception without modifying the original flow code.

I'll think about more juicy use cases tonight.

--
Stefano.