Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <45AA52D9.3050700@nada.kth.se>
Date: Sun, 14 Jan 2007 16:57:13 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: What is the deal with "blocks"
References: <d62d97d95c982f2101603f2fc7322abf@comcast.net>
 <45944E75.9000502@nada.kth.se>
 <4b6779bc01ec27c6562ef96b43e92a3f@wrinkledog.com>
 <459ADE65.9060907@nada.kth.se> <7a43112048ab0cd841d8610059e196a4@comcast.net>
 <459BC8B4.8020301@nada.kth.se>
In-Reply-To: <459BC8B4.8020301@nada.kth.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

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

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.
> 
> WDYT?
> 
> /Daniel
>