cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Piroumian" <>
Subject Re: [Proposal] Implementing XMLForm with Flow
Date Mon, 09 Dec 2002 13:21:01 GMT

(Sorry for late jump in)

From: "Ivelin Ivanov" <>
> This is actually a good example.
> For fairness sake, I haven't seen many J2EE applications which forward to
> login from different spots though.
> J2EE containers usually take care of login and return to original URL.

According to Servlet specification, in case of the container managed
authentification, you can be forwarded to login from any URL that is
constrained in web.xml. After succesful login you are redirected to the page
you've originally requested.

More comments below:

> From: "Christopher Oliver" <>
> > >
> > >Until now, it has shown to me a simple way to program simple
> applications.
> > >
> > >
> > >
> > Well, actually I think the more complex the control flow the more the
> > flow layer will really shine. Consider the login example, where you
> > could need to login at any point during the application. With the flow
> > layer you simply write a function login(), and call it from any place
> > during your application. After completion of the login sequence, you are
> > automatically returned to the calling page. Something like this
> > (although still a simple example) is extremely difficult to implement
> > with state-machine code. Other complex control flow constructs
> > (conditional branching,  loops, etc) are straightforward with the flow
> > layer but virtually impossible to comprehend with state-machine like

Recently, I've been dealing with a lot of state-machine based logic and I
must admit that although understanding state-machines is not a simple task
(including sub-states, shallow and deep histories, actions, events, etc.),
but it's not a very difficult task to construct complex flows with state

In case of the flow script you should place login() function call in every
function that needs authorized access, while for the state machine approach
you could create a superstate - AuthorizedState - for all the sub-states
that needs authenticated user.

In the project I'd been working, we'd been generating our state machine
descriptions directly from a UML modeling tool (it was XMI format), then it
were processed by an XSLT to our (simpler) format. (The source code was not
related to Cocoon neither it was open source, unfortunately)

Just my <i18n:currency value="0.02"/>


> >
> > Regards,
> >
> > Chris
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message