You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Torsten Curdt <tc...@apache.org> on 2007/07/16 15:23:14 UTC
spring webflow
> I really, really want to integrate Cocoon with Spring WebFlow as I
> feel that that is a much more workable solution than trying to
> build applications using flowscript or javaflow and this only
> really makes sense with 2.2 since it is Spring based.
You brought this already a couple of times.
Years and years ago (when I was still working at dff) we developed a
xml based flow engine way before what we call flow these days
existed. It was so horrible to maintain that we dropped it. Maybe
just the lack of tools ...or maybe just the lack of resources writing
those tools ...but I am still afraid when ever someone pushes into a
similar direction. There was also a talk at FOSDEM about such an
approach and I only barely could hold back to comment during his
talk ...he was so excited and convinced about the solution. For us
just a minimal flow resulted in so much xml ...bah! Make sure you
evaluate it's what you really want before you go down that road.
Just my 2 cents
cheers
--
Torsten
Re: spring webflow
Posted by Ralph Goers <Ra...@dslextreme.com>.
Yes, I've brought this up a couple of times in the past.
First, I tried to use the sitemap as the flow controller for my business
logic. This worked fine for small and simple things. However, when the
page flow turned into anything of any substance it quickly became
unworkable.
I then looked at javaflow. I liked it because it was Java. But I also
hated it because it was Java. Managing the application flow through a
programming language just makes for something that is still pretty messy
but it is hard to change.
My one adventure into flowscript was quite by accident. A coworker used
one of Cocoon's sample calculators in a website. After the release went
live threads started looping periodically. After reviewing dumps I
discovered that Rhino was causing the loop. As it was virtually
impossible to figure out what was causing the problem we pretty much
decided flowscript was not such a great idea. Secondly, it really isn't
that much better than Javaflow in terms of being hard to change the flow.
We've been developing some of our applications using JSF. While it
isn't all that bad, when I compare it with Spring WebFlow I find I just
like the way it works better. Since we wrap all of our JSF portlets
with Spring anyway it just seems to make more sense.
Finally, I've always felt that Cocoon's strength was as a View
generator. I could never recommend that folks use some of the blocks as
they are huge security problems are horribly clumsy ways to access the
business data. That being said, as a View generator Cocoon is
fabulous. So to me, since 2.2 is already Spring based it just seems
that providing support for integrated WebFlow makes a lot of sense.
Ralph
Torsten Curdt wrote:
>> I really, really want to integrate Cocoon with Spring WebFlow as I
>> feel that that is a much more workable solution than trying to build
>> applications using flowscript or javaflow and this only really makes
>> sense with 2.2 since it is Spring based.
>
> You brought this already a couple of times.
>
> Years and years ago (when I was still working at dff) we developed a
> xml based flow engine way before what we call flow these days existed.
> It was so horrible to maintain that we dropped it. Maybe just the lack
> of tools ...or maybe just the lack of resources writing those tools
> ...but I am still afraid when ever someone pushes into a similar
> direction. There was also a talk at FOSDEM about such an approach and
> I only barely could hold back to comment during his talk ...he was so
> excited and convinced about the solution. For us just a minimal flow
> resulted in so much xml ...bah! Make sure you evaluate it's what you
> really want before you go down that road.
>
> Just my 2 cents
>
> cheers
> --
> Torsten
Re: spring webflow
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Juan José Vázquez Delgado skrev:
> Sure, very clear!
>
> I wish you code a tutorial or a minimal web app about this including
> jx templates, parameters, etc.
As indicated earlier, my interest for WebFlow doesn't go that far. For
state full webapps I'm personally fine with flowscripts or javaflow and
for new development I would prefer putting the flow in an Ajax client
and have a REST based server.
If anyone would like to create some samples on how to use Cocoon and
Spring WebFlow I'm prepared to give some help and feedback, but I'm not
going to drive such an effort.
/Daniel
Re: spring webflow
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
Sure, very clear!
I wish you code a tutorial or a minimal web app about this including jx
templates, parameters, etc.
thanks.
On 7/18/07, Daniel Fagerstrom <da...@nada.kth.se> wrote:
>
> Juan José Vázquez Delgado skrev:
> > 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"/>
> >
> > </bean>
> >
> > If i want to use Cocoon views instead JstlView, what i should write as
> "viewClass" property?
> >
> You don't need to have any value for the viewClass property. Its default
> value for the InternalResourceViewResolver is the class
> InternalResourceView, which just call a webapp internal resource
> (servlet or JSP) through a request dispatcher.
>
> So if the Cocoon sitemap servlet is mounted at "/cocoon-view/*" in the
> servlet mapping in web.xml, and the sitemap has match rules with
> "searchCriteria" etc as patterns, you just needs to configure the prefix
> property in the viewResolver as "/cocoon-view/". And then it should work.
>
> /Daniel
>
>
Re: spring webflow
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Juan José Vázquez Delgado skrev:
> 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"/>
>
> </bean>
>
> If i want to use Cocoon views instead JstlView, what i should write as "viewClass" property?
>
You don't need to have any value for the viewClass property. Its default
value for the InternalResourceViewResolver is the class
InternalResourceView, which just call a webapp internal resource
(servlet or JSP) through a request dispatcher.
So if the Cocoon sitemap servlet is mounted at "/cocoon-view/*" in the
servlet mapping in web.xml, and the sitemap has match rules with
"searchCriteria" etc as patterns, you just needs to configure the prefix
property in the viewResolver as "/cocoon-view/". And then it should work.
/Daniel
Re: spring webflow
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
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"/>
</bean>
If i want to use Cocoon views instead JstlView, what i should write as
"viewClass" property?
thanks.
j.
On 7/17/07, Daniel Fagerstrom <da...@nada.kth.se> wrote:
>
> 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
>
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/applicationContext.xml
> for what is needed. This in turn will load all bean configs frm the
> Cocoon blocks.
> * 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
> (
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/web.xml
> ).
> * Then you of course need to write a sitemap and implement the views in
> Cocoon.
> * In WebFlow the views has short symbolic names "searchCriteria",
> "searchResults", "details" etc. 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.
> * 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
> be nice.
>
> /Daniel
>
>
Re: spring webflow
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Peter Hunsberger skrev:
> On 7/17/07, Daniel Fagerstrom <da...@nada.kth.se> wrote:
>
> <snip/>
>
>> 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
>> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/applicationContext.xml
>>
>> for what is needed. This in turn will load all bean configs frm the
>> Cocoon blocks.
>> * 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
>> (http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/web.xml).
>>
>
> Can you explain why someone would prefer one approach over the other?
If you build a small webapp consisting of just one sitemap and don't use
any servlet services from other blocks, you save a couple of lines of
configurations (and the need to learn about servlet service fw), by
using the "classical" style. If you upgrade a 2.1 webapp to 2.2 it might
also be reasonable to go this way as a first step.
But as soon as you want to modularize your webapp and reuse other blocks
with servlet services, the servlet service style, is the way to go. Also
as we are converting our blocks, like e.g. the forms blocks, to make
their resources available through servlet services, the servlet service
style is becoming the preferable style.
/Daniel
Re: spring webflow
Posted by Peter Hunsberger <pe...@gmail.com>.
On 7/17/07, Daniel Fagerstrom <da...@nada.kth.se> wrote:
<snip/>
> 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
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/applicationContext.xml
> for what is needed. This in turn will load all bean configs frm the
> Cocoon blocks.
> * 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
> (http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/web.xml).
Can you explain why someone would prefer one approach over the other?
<snip/>
--
Peter Hunsberger
Re: spring webflow
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/applicationContext.xml
for what is needed. This in turn will load all bean configs frm the
Cocoon blocks.
* 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
(http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/web.xml).
* Then you of course need to write a sitemap and implement the views in
Cocoon.
* In WebFlow the views has short symbolic names "searchCriteria",
"searchResults", "details" etc. 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.
* 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
be nice.
/Daniel
Re: spring webflow
Posted by Carsten Ziegeler <cz...@apache.org>.
Bart Molenkamp wrote:
> Cocoon's SoC made writing web applications better because of the strong
> separation of logic, content and styling. And javaflow improved it because
> it took some request/response details away. I think Wicket has achieved
> the same goal, but I think it's more productive to use than Cocoon is
> these days. Maybe Cocoon should focus on XML transformation stuff again,
> and not trying to integrate yet anohter product...
>
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.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
RE: spring webflow
Posted by Bart Molenkamp <b....@bizzdesign.nl>.
I'm not sure if Cocoon should be used for writing web applications at
all. If you want to write a simple application, you need to write (and
learn) the sitemap, flowscript and probably JXTemplate. If you want to
use cforms, you need to know how to write form definitions, form
templates and maybe even form bindings. If you want to apply some
styling you need to know about XSLT as well.
And it even makes it more difficult if you want to reuse some of these
parts (try to extend or override parts in cforms, jxtemplate or flow -
it wasn't designed for this).
I've switched to use Wicket for the new application that we've been
creating here. I think it's much easier to create web applications with
wicket (because one of the things that make it easier to use is that it
takes the request/response cycles away). It's back to basic html (or
xhtml) with Java. And onf of the best things is that you can reuse
and extend your components (including reuse of markup).
Cocoon's SoC made writing web applications better because of the strong
separation of logic, content and styling. And javaflow improved it because
it took some request/response details away. I think Wicket has achieved
the same goal, but I think it's more productive to use than Cocoon is
these days. Maybe Cocoon should focus on XML transformation stuff again,
and not trying to integrate yet anohter product...
Just my 2 cents.
> -----Oorspronkelijk bericht-----
> Van: Carsten Ziegeler [mailto:cziegeler@apache.org]
>
> To be honest I'm not sure if javascript is better than xml :) Though I
> don't like both of them when it comes to describing a flow, Spring
> Webflow as imho to big plus points: a visual editor and it's
> well known
> outside of Cocoon. This doesn't imply that it's really better
> or better
> usable.
Re: spring webflow
Posted by Torsten Curdt <tc...@apache.org>.
On 16.07.2007, at 15:35, Carsten Ziegeler wrote:
> Torsten Curdt wrote:
>>> I really, really want to integrate Cocoon with Spring WebFlow as I
>>> feel that that is a much more workable solution than trying to build
>>> applications using flowscript or javaflow and this only really makes
>>> sense with 2.2 since it is Spring based.
>>
>> You brought this already a couple of times.
>>
>> Years and years ago (when I was still working at dff) we developed
>> a xml
>> based flow engine way before what we call flow these days existed. It
>> was so horrible to maintain that we dropped it. Maybe just the
>> lack of
>> tools ...or maybe just the lack of resources writing those
>> tools ...but
>> I am still afraid when ever someone pushes into a similar direction.
>> There was also a talk at FOSDEM about such an approach and I only
>> barely
>> could hold back to comment during his talk ...he was so excited and
>> convinced about the solution. For us just a minimal flow resulted
>> in so
>> much xml ...bah! Make sure you evaluate it's what you really want
>> before
>> you go down that road.
>>
>> Just my 2 cents
>>
> To be honest I'm not sure if javascript is better than xml :)
...it's just less verbose :)
> Though I
> don't like both of them when it comes to describing a flow, Spring
> Webflow as imho to big plus points: a visual editor and it's well
> known
> outside of Cocoon. This doesn't imply that it's really better or
> better
> usable.
I guess those were also the two things that we were missing those
days :)
cheers
--
Torsten
Re: spring webflow
Posted by Carsten Ziegeler <cz...@apache.org>.
Torsten Curdt wrote:
>> I really, really want to integrate Cocoon with Spring WebFlow as I
>> feel that that is a much more workable solution than trying to build
>> applications using flowscript or javaflow and this only really makes
>> sense with 2.2 since it is Spring based.
>
> You brought this already a couple of times.
>
> Years and years ago (when I was still working at dff) we developed a xml
> based flow engine way before what we call flow these days existed. It
> was so horrible to maintain that we dropped it. Maybe just the lack of
> tools ...or maybe just the lack of resources writing those tools ...but
> I am still afraid when ever someone pushes into a similar direction.
> There was also a talk at FOSDEM about such an approach and I only barely
> could hold back to comment during his talk ...he was so excited and
> convinced about the solution. For us just a minimal flow resulted in so
> much xml ...bah! Make sure you evaluate it's what you really want before
> you go down that road.
>
> Just my 2 cents
>
To be honest I'm not sure if javascript is better than xml :) Though I
don't like both of them when it comes to describing a flow, Spring
Webflow as imho to big plus points: a visual editor and it's well known
outside of Cocoon. This doesn't imply that it's really better or better
usable.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org