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 Sat, 23 Aug 2003 08:17:46 GMT
Stefano Mazzocchi wrote:
> 
> On Tuesday, Aug 19, 2003, at 22:41 Europe/Rome, Christian Haul wrote:
--------------------------------------------^^^^ Interesting,didn't know 
that, thought to have been in Darmstadt ;-)

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

I'm going to ignore this comment.

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

Well, probably yes. Although with very little organization, SoC can be
achieved for this use case. But in general, you are right.

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

Right, one can easily start a complex flow as error handling.

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

Absolutely. I don't want to argue about AOP in general. It's just that
your example is only touching the concept and for this we already have
a solution. This solution is not as elegant as AOP but it's here and
it's usable. We have some other features we all agree are really needed
i.e. blocks. I'm not at all against AOP in Rhino. I just would like us
to be more focussed on Cocoon, that's all ;-)

> I'll think about more juicy use cases tonight.

Great!

	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