You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2008/08/14 10:47:48 UTC
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...
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?
--
Grzegorz Kossakowski
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...
Posted by Reinhard Pötz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> 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...
>
Yep, and thanks to JNet the servlet protocol also works for java.net.URL
objects which wasn't the case when this feature was added.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
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...
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
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...
Posted by Reinhard Pötz <re...@apache.org>.
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.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________