cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: What is the deal with "blocks"
Date Sun, 14 Jan 2007 15:57:13 GMT
I have started to implement what we discussed bellow.

I started by applying all outstanding patches that I found and then took 
a copy of the blocks-fw stuff.

The blocks-fw-impl module will not be removed until the new stuff 
stabilizes. I don't recommend anyone to start update yet as there are a 
number of refactorings and changes I'd like to do first.


Daniel Fagerstrom skrev:
> Mark Lundquist skrev:
>> On Jan 2, 2007, at 2:36 PM, Daniel Fagerstrom wrote:
>>     Finding some term that doesn't contain the word block for
>>     "polymorphic servlet services", would be much less of a problem as
>>     it is different from the original block concept and not that many
>>     people have used the blocks-fw yet.Fair enough :-)
>>     So if someone have suggestions for a better terminology for the
>>     "polymorphic servlet services" I at least would be prepared to go
>>     for it.
>> How about just "services"? E.g.,
>> • services-fw
> I would prefer servlet-services-fw or just servlet-services.
>> • ServiceServlet (or "CocoonServiceServlet"?)
> ServletService would be OK.
>> • ServiceContext (or "CocoonServiceContext"?)
> ServiceServletContext maybe.
>> • "service:" protocol
> To generic in my taste. I think that "servlet:" protocol would describe 
> pretty well what it all is about. Also it is implemented using the named 
> dispatcher mechanism in the ServletContext, so it really is named 
> servlets that the protocol dispatches to.
> Also we could add some Spring bean factory and XML-schema based 
> configuration, that put the focus on the embedded servlet instead of the 
> "blocks fw" so instead of:
>   <bean id="org.apache.cocoon.blocks.sample.block1" class="org.apache.cocoon.blocks.BlockServlet">
>     <property name="mountPath" value="/cocoon-blocks-fw-sample1"/>
>     <property name="servletClass" value="org.apache.cocoon.sitemap.SitemapServlet"/>
>     <property name="blockContextURL" value="blockcontext:/cocoon-blocks-fw-sample/test1"/>
>     <property name="properties">
>       <map>
>         <entry key="foo" value="bar"/>
>       </map>
>     </property>
>       <property name="connections">
>       <map>
>         <entry key="test2" value-ref="org.apache.cocoon.blocks.sample.block2"/>
>       </map>
>     </property>
>   </bean>
> we could have something like:
>   <bean id="org.apache.cocoon.blocks.sample.block1" class="org.apache.cocoon.sitemap.SitemapServlet">
>     <servlet:context mountPath="/cocoon-blocks-fw-sample1"
>                      contextPath="blockcontext:/cocoon-blocks-fw-sample/test1">
>       <servlet:context-param name="foo" value="bar"/>
>       <servlet:connection name="test2" value-ref="org.apache.cocoon.blocks.sample.block2"/>
>     </servlet:context> 
>   </bean>
> The point here is that the sitemap servlet is considered as an ordinary 
> bean and the elements in the servlet name space sets up a bean factory 
> that embeds the sitemap servlet in a block servlet and make sure that 
> the somewhat special life cycle of servlets is respected. Using a 
> servlet in the Spring framework would be as easy as:
>   <bean id="myservlet" class="com.mycompany.MyServlet">
>     <servlet:context mountPath="/my">
>   </bean>
> And would be usable outside Cocoon.
> Another advantage of dropping the prefix "block" from the "polymorphic 
> servlet service" stuff is that I get the impression that many people 
> believe that anything that is prefixed with block is incredibly 
> complicated. While the current stuff actually isn't.
> /Daniel

View raw message