Something like Spring WebFlow

[Artyom]

We're trying to decide whether to port our existing j2ee app (Spring
2.5 ish) to Grails or Play. We make heavy use of WebFlow 2.0 and
kinda like the paradigm. Is there something similar or equivalent in
Play? ie, something that abstracts out a flow into a simple set of
states and decisions?

thanks
Artyom

[sas]

I think that in play's approach, that role is covered by the
controllers and conventions

[Artyom]

Thanks, SAS

Well, is it easy to outline flow logic, without having convoluted
logic end up in controllers? That is really the issue. Could you
or someone elaborate on this with a brief example of comparison?

[sas]

well you could certainly use renderArgs.put("key", value) and
render("@action") or render("template.html") to dynamically change the
flow logic, or even read it from a (yarg!) xml file, if you wish, but
I think that would be going against play philosophy that is based on
conventions...

maybe you should carefully think about the way you organize your
controllers, actions and templates, in order to make them self evident
and ease maintainability...

anyway I think that convoluted logic is more hard to follow from xml
files than from well organized java code (in which case you can reuse
and set sensible default conventions), but that's just my opinion...

[Artyom]

Thanks sas.

With all due respect though, I'm not sure the issue has much to do
with XML vs Java (or any other language for that matter). Thinking
of parts of web apps as a "state machines" has a very obvious benefit
in mre complex apps. For simple sites (not SAS "apps"), there is no
need. But for shopping carts, and other types of "wizard-like"
uses, it helps to be able to abstract out the flow logic, and be able
to string simple pieces together rather than thinking merely of model
and view (with a simple controller helper layer). That is the key
feature that I was enquiring about, and I don't much care what
language it would get coded in.

Your advice to "rethink" seems to miss this. There really is a
plurality of real-world uses for web technologies, some very simple
and some quite complex.

As a side-note, though XML has a bad association from the old days of
J2EE (--which I know very well having been there almost from the
beginning), I think defining states and flow logic is one of its *most
appropriate* uses. It's quite well suited to it.

In fact, back webflow existed, I was on a team that ended up
implementing something very similar it for a large framework we were
supporting. It was not for lack of understanding of the benefits of
small stateless controllers etc... it was because there are more
complex cases where you want to externalize the logic from a single
controller or group of controllers. Otherwise over time, you tend to
end up with the bloat to which I referred. That is a missing piece
in many web technologies, not just the old J2EE (or Play! it
seems...). That is exactly why the Spring people devised webflow.
IMHO, It's actually one of the few things they got right.

On Oct 25, 5:58 pm, sas <open...@gmail.com> wrote:
> well you could certainly use renderArgs.put("key", value) and
> render("@action") or render("template.html") to dynamically change the
> flow logic, or even read it from a (yarg!) xml file, if you wish, but
> I think that would be going against play philosophy that is based on
> conventions...
>
> maybe you should carefully think about the way you organize your
> controllers, actions and templates, in order to make them self evident
> and ease maintainability...
>
> anyway I think that convoluted logic is more hard to follow from xml
> files than from well organized java code (in which case you can reuse
> and set sensible default conventions), but that's just my opinion...
>
> On 25 oct, 16:53, Artyom <artyom...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Thanks, SAS
>
> > Well, is it easy to outline flow logic, without having convoluted
> > logic end up in controllers?   That is really the issue.   Could you
> > or someone elaborate on this with a brief example of comparison?
>
> > On Oct 24, 8:14 pm, sas <open...@gmail.com> wrote:
>
> > > I think that in play's approach, that role is covered by the
> > > controllers and conventions
>
> > > On 23 oct, 17:32, Artyom <artyom...@gmail.com> wrote:
>
> > > > We're trying to decide whether to port our existing j2ee app (Spring

> > > > 2.5 ish) to Grails or Play.   We make heavy use ofWebFlow2.0 and