cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: svn commit: r685792 - in /cocoon/trunk/core: cocoon-core/ cocoon-core/src/main/java/org/apache/cocoon/spring/ cocoon-core/src/main/resources/META-INF/cocoon/spring/ cocoon-servlet-service/cocoon-servlet-service-components/ cocoon-servlet-service/cocoon...
Date Fri, 15 Aug 2008 15:19:10 GMT
Reinhard Pötz pisze:
> Grzegorz Kossakowski wrote:
>> reinhard@apache.org pisze:
>>> Author: reinhard Date: Thu Aug 14 00:43:31 2008 New Revision: 685792
>>>
>>> URL: http://svn.apache.org/viewvc?rev=685792&view=rev Log: The
>>> BlockPathPropertyPlaceholderConfigurer module is *usually* only useful
>>> if the SSF is used
>>> together with Cocoon. In this case you always need the SSF-components.
>>> Hence it's best to move it
>>> to into this module so that Cocoon 2.2 can still be run in the
>>> 'classic' mode.
>> Somehow agreed. It looks like nobody is going to use SSF+Blocks
>> infrastructure without Cocoon Core, right? :-)
>>
>>> (I can't help myself but somehow the
>>> BlockPathPropertyPlaceholderConfigurer seems to be a hack
>>> anyway ...)
>> What do you mean by that? What makes it hacky?
> 
> I'm still not convinced that we should expose block resources directly.
>  But there are use cases for it
> (http://cocoon.markmail.org/message/vr72n4vr7lfpppfe) and we've already
> introduced this contract so it probably doesn't make much sense to
> discuss this again.

Ah, thanks to bringing this thread back to my mind! :-)

Yes, I agree that in 99% cases one should not expose block's resources but still there might
be some 
egde-cases were it's needed.

The real task to be done is to make people more aware of servlet: protocol...

-- 
Grzegorz Kossakowski

Mime
View raw message