Re: [Springframework-developer] Support for state/controller chaining in Portlets? (not quite webflow)

[Steven D. <ste...@gm...>]

Regarding the WebFlow FAQ entry, this should not be a limitation for
CRUD applications. For example, you should never call the remove
action before you have displayed the related record which is by itself
an example of a workflow. The same for detail screens, you should
first pass through a table view or another detail screen.

I'm not sure about the back button, maybe somebody from the WebFlow
crew could comment on that.

On 5/17/05, Tim Kettering <tim...@vi...> wrote:
>=20
> Hi everyone,
>=20
> I'm just throwing this out here to see what other people have to say.  I =
can
> see from the list that there are a few developers actively working on por=
tal
> solutions using Spring MVC.  We are starting on our first project using t=
his
> as well, and one of the issues I'm trying to figure out now is the matter=
 of
> maintaining state in a portlet.
>=20
> In a typical CRUD example, if we have a portlet to display, edit and maan=
ge
> information about a certain object, like a Book. We'd have view, edit and
> delete functionality for example.
>=20
> In a typical non-portlet webapp, we could easily split those up across
> different servlets for fine-grained areas of responsibility.
>=20
> But it's not as simple with portlets, because there are limitations on wh=
at
> can be done, and essentially, all requests would need to go thru a single
> portlet configuration.
>=20
> So, it no longer become sufficient to configure a simple portlet controll=
er
> for a portlet.  There needs to be a way to maintain state and to delegate
> the request/response process to different types of controllers depending =
on
> the state.  Like a View page would need to go thru a derivation of
> BaseCommandController, an Edit page would go thru SimpleFormController.
>=20
> And not to mention adding yet another dimension when considering portlet
> modes as well!
>=20
> This article at IBM Developerworks pretty much covers the same issue I am
> bringing up:
>=20
> http://www-106.ibm.com/developerworks/websphere/library/techarticles/0312=
_ha
> nis/hanis1.html
>=20
> I did look at Spring's WebFlow a few days ago to see if it could address =
our
> issue, but in the Webflow FAQ, it pretty much states that WebFlow should =
not
> be used in cases where the user will be using back-button, or indetermina=
te
> actions not within a strict flow.
>=20
> So that kinda leaves me back at square one.  After some discussion with m=
y
> co-worker, I would imagine that this is a common problem for any Spring
> portlet developer creating more than just simple portlet functionality.  =
And
> that as Spring portlet support matures, this will be a more common issue =
for
> everyone.  Hence this email to the list.
>=20
> I'm now wondering how some of you have addressed this problem, and whethe=
r
> there is a need for Spring's portlet support, to be in Spring 1.3 to incl=
ude
> some way to configure and facilitate a state process, maybe even based on
> WebFlow's state machine - although I have only given WebFlow's state
> functionality a brief look.
>=20
> Thanks in advance,
>=20
> -tim
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=3D7412&alloc_id=3D16344&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20


--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart