cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <alexander.klimetsc...@mindquarry.com>
Subject Re: Configuring BlockServlets via properties and sitemap reloading for blocks
Date Tue, 17 Oct 2006 10:41:28 GMT
Hi,

thanks for your answer! Things are really getting better now, as I got 
reloading to work (https://issues.apache.org/jira/browse/COCOON-1934) as 
written in the other mail.

Daniel Fagerstrom schrieb:
>> 1) I'd like to configure the mountPath to the blocks in the webapp, 
>> because the blocks itself are generic; I have tried it with a 
>> properties file manually placed in WEB-INF/cocoon/properties that sets 
>> the mountPath:
>>
>> com.domain.package.blockA.mountPath=foo
>>
>> But this does not work. How can I override the setting in the bean 
>> config XML with a property?
> The possibility to override bean properties is very new and I have not 
> tested it yet, see 
> http://marc.theaimsgroup.com/?t=116012787900003&r=1&w=2 for a 
> description of how it is supposed to work. I am not certain that it is 
> tested yet. Maybe Carsten can say something about it.

I got it working when I placed the properties file in my webapp-module 
under WEB-INF/cocoon/spring and naming the property

<bean-id>/<param>=<value>

so for example:

com.domain.package.blockA/mountPath=/foo

> We have some ideas about how to get rid of the need for the deployer in 
> the development cycle. See 
> http://marc.theaimsgroup.com/?t=116013240800001&r=1&w=2, 
> http://marc.theaimsgroup.com/?t=116034430600002&r=1&w=2 and 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=116035392308084&w=2 for 
> that discussion.

That would indeed be very nice. But how does the reloading work then? 
Deploy a special jar into cocoon/libs that somehow points to its 
original source folders?

>> I'd imagine a deployer that recognizes the 
>> -Dorg.apache.cocoon.mode=dev and then configures the webapp to work as 
>> above. I could do some work on the deployer plugin if those points are 
>> resolved.
> Patches are always welcome.

Will see if I modify the deployer for that case. My manual solution (see 
the JIRA issue) works so far, so this might happen later. Maybe someone 
has changed the way of deploying by then ;-)

> I think there are two main scenarios: You use a ordinary PipelineServlet 
> for the root sitemap and BlockServlets for the blocks that you use. Or 
> you let everything including the root sitemap be a block.
> 
> To make it easy to start using blocks from existing Cocoon webapps we 
> should probably make the first alternative easy to use. In that scenario 
> you typically will mount a SitemapServlet containing the root sitemap at 
> "/", and the DispatcherServlet at e.g. "/blocks". The block protocol 
> doesn't work from the root sitemap to the blocks, as the block protocol 
> is designed for inter block communication and require that blocks are 
> wired together with Spring. It might work with 
> "http:/blocks/myBlock/foo", not certain though. I'm thinking about 
> implementing a "blocks:" protocol for this scenario. It would use the 
> global bean id for the block instead of the bean local property name. 
> There was something like that in an early incarnation of the blocks 
> framework.

Does this mean I could mount a BlockServlet inside a sitemap via 
map:mount src="blocks:<global-bean-id>"? That sounds very cool and 
should IMHO be part of the blocks-framework before releasing 2.2.

> For the case when also the main sitemap is in a block, you can just wire 
> it to the used blocks and use the block: protocol. As long as the block 
> deployer is required for updating the block, this would be rather 
> painful. We really need to do something about the deployment.

Reloading does work now with my patch, so I'll try that! No more 
SitemapServlet inside the web.xml configuration ;-)

> Thanks for testing the blocks framework and for the feedback.

Well, I really like the inheriting feature because it allows you to 
extract general stuff out of your sitemap into an "abstract" super 
block. And we got a case where we need that. If you put together 
components in Cocoon and actually program in sitemaps, you have to be 
able to separate stuff and let sitemaps itself stand as new components - 
which is what blocks now provide.


Alex

-- 
Alexander Klimetschek
http://www.mindquarry.com


Mime
View raw message