Daniel, very interesting but i´m not sure what you mean with:
"You need to configure a org.springframework.web.servlet.view.InternalResourceViewResolver bean with the prefix and suffix that needs to be added to the short symbolic name to create the URL for the corresponding Cocoon view.".
Which should be the "Cocoon view"?. For example, with this configuration:
<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver ">
<property name="viewClass" value="org.springframework.web.servlet.view.JstlView"/>
<property name="prefix" value="/WEB-INF/jsp/"/>
<property name="suffix" value=".jsp"/>
If i want to use Cocoon views instead JstlView, what i should write as "viewClass" property?
Carsten Ziegeler skrev:
> I agree with you that Cocoon should not integrate additional stuff -
> there is too muc in it already. Now, I think Cocoon should do the
> opposite and just provide the framework and enable you to use other
> stuff. Now, this sounds a little bit like the "you can do everything but
> you have to figure out yourself how", I know. But if you look at the
> switch to Spring, it's the way I think it should be. We removed our own
> container implementation (nearly completly if we forget about the avalon
> support) and you can integrate Cocoon into Spring.
> And I guess the same could be try with Spring WebFlow, so this would
> mean that you don't have to care about all the current flow stuff in
> Cocoon and just use what is out there.
Exactly, I think you can use Spring WebFlow with Cocoon as a view
generator without writing any integration code at all. With 2.2, Cocoon
is just a servlet that gets its Spring managed components through the
standard context listener mechanism. So using Cocoon as a view shouldn't
be different from using any other servlet based framework as view,
rather it should be easier as Cocoon is Spring based.
I read the WebFlow tutorial
http://www.ervacon.com/products/swf/intro/index.html to see what it all
is about. I guess I'm about as excited as Torsten about writing finite
state machines in XML ;) But nether mind about that, let us see how
WebFlow could be used with Cocoon as view layer.
I will start from the WebFlow tutorial and give an outline on what needs
to be modified:
* The root application context (services-config.xml) needs to be
extended with the Cocoon components. See
for what is needed. This in turn will load all bean configs frm the
* If you want to use Cocoon in the "classic" style the
o.a.c.servlet.SitemapServlet needs to be configured in the web.xml. If
you want to use the servlet service style the
o.a.c.servletservice.DispatcherServlet needs to be configured
* Then you of course need to write a sitemap and implement the views in
* In WebFlow the views has short symbolic names "searchCriteria",
"searchResults", "details" etc. You need to configure a
with the prefix and suffix that needs to be added to the short symbolic
name to create the URL for the corresponding Cocoon view.
* IIUC, InternalResourceViewResolver exposes model objects as request
attributes and flow, state and event identifiers as request parameters.
So you could probably just use JXTG to access what is needed for the view.
I haven't tried anything of the above, so there could of course be
further complications. But considering that the view layer isn't part of
the web flow it is at least designed to work with other view layers.
So, AFAICS, we don't need any WebFlow integration. But a sample
application and a tutorial, to help people get started, would of course