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
