That seems like a very imperfect fix for an almost impossible problem.
Having an extra parameter on the link won't stop a user from right clicking
on the link and saying "open in another window" and having 2 "conversations"
with the same conversation key.  To my knowledge there's just no way to
accomplish it cleanly and completely, so you might as well embrace the way
the web works and go with it rather than trying to swim upstream.  But
that's just one man's opinion.
  (*Chris*)

On Thu, Dec 10, 2009 at 11:27 AM, Gabriel Belingueres <belingue...@gmail.com
> wrote:

> Granted, most people implement wizards this way, but the most
> compelling use of storing state in conversation scope (IMO) is to
> allow correct behavior when a user clones a browser window, and then
> allow better support for the back button. Even with conversation
> support the pages still need to pass along at least one request
> parameter: the conversation id, so in general terms you end up writing
> the same thing only that instead of passing actual data as request
> parameters you pass only a key to some other abstraction.
>
> Some conversation implementations are not compelling at all. See the
> struts2scopeplugin for example, it stores only one conversation per
> user session which is of course useless for multi-window apps.
>
> I've been researching the conversation features in JBoss Seam and
> Spring Web Flow, which I think are the 2 more important frameworks
> supporting it. The most sophisticated one is SFW which pretty much
> abstract the whole page and actions interactions (the flow) into one
> file, that is an XML file describing a FSM of the states the app is in
> a given time. For that thing to work, the request parameter that the
> app pass along in the pages is a composite between the conversation id
> and the "continuation id" (a fancy name for naming the current state
> in the flow FSM the app is in.)
>
> Also the conversation scope is the basis for other features like
> supporting the handy session-per-conversation pattern in ORMs.
>
> What I finally mean is that I seriously consider conversation scope
> support something important (at least for the kind of apps I work in.)
>
> Regards
> Gabriel
>
> 2009/12/10 Andreas Joseph Krogh <andr...@officenet.no>:
> > On Thursday 10. December 2009 15.31.15 Alex Siman wrote:
> >>
> >> Wes Wannemacher wrote:
> >> >
> >> > "Everything is tied to either the request
> >> > or the session, I can't build wizard-style views"
> >> >
> >> Yeah, we need wizards sometimes.
> >
> > I would argue that it would be nice to have, but not a must. Most
> implementations I've seen of "conversation"-scope are rather messy and don't
> provide anything beyond what you can achieve with
> ScopedModelDriver(scope=session) and some custom-code. I've built several,
> robust, wizard-like UIs using Struts2 without any problems.
> >
> > --
> > Andreas Joseph Krogh <andr...@officenet.no>
> > Senior Software Developer / CTO
> > ------------------------+---------------------------------------------+
> > OfficeNet AS            | The most difficult thing in the world is to |
> > Rosenholmveien 25       | know how to do a thing and to watch         |
> > 1414 TrollÄsen          | somebody else doing it wrong, without       |
> > NORWAY                  | comment.                                    |
> >                        |                                             |
> > Tlf:    +47 24 15 38 90 |                                             |
> > Fax:    +47 24 15 38 91 |                                             |
> > Mobile: +47 909  56 963 |                                             |
> > ------------------------+---------------------------------------------+
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> > For additional commands, e-mail: dev-h...@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
>

Reply via email to