You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Radha Krishna <st...@yahoo.com> on 2007/11/23 15:51:33 UTC
Wizard like Screens
Hi,
I have a wizard like screen where i need to pass the selected values (2 text box) at first page to last page,last page to again first page.
Can anyone tell me the best solution how could i achive this without storing values in to Session?
Thanks.
---------------------------------
Never miss a thing. Make Yahoo your homepage.
Re: [OT] session state (was Re: Wizard like Screens)
Posted by Gary Affonso <gl...@greywether.com>.
Jeromy, Ted...
Thanks for the education. The Blog link Jeromy provided was a good
read. And the blog comments (particularly the last one from gregjor)
were even more educational.
Even after reading a well-written blog titled "The Session is Evil" I'm
now feeling better than ever about using the Session. As gregjor
pointed out in his comment (on the blog entry), what really should be
said is...
"Some apps-server's implementations of the session are evil for some use
cases (such as clustering)".
And for us, we're happy with our App server's implementation for our use
case. I will not be avoiding the session anytime soon for my non-ajax
webapps.
When we do a RIA interface to our apps (thinking flex at this point)...
we'll almost certianly take a look at client-side state. It's an
obvious fit.
When we cluster we *might* look at client-side state, but will probably
just put together a server-side solution that's cluster friendly.
Thanks again guys!
- Gary
Ted Husted wrote:
> Just to emphasize what Jeromy is saying, the key words are "scalable"
> and "cluster". In the case of an intranet application with a set user
> base that won't be clustered, *not* using session could be evil,
> since the alternatives tend to be more work to implement and maintain.
>
> In physics, we have very different rules that apply for large-scale
> and small-scale calculations. We need to keep in mind that the same
> principle applies to web development. There are different rules for
> large-scale and small-scale deployments.
>
> Though, I do know large-scale deployments that do use session-state.
> In fact, they use *a lot* of session state, because, in their case,
> it's cheaper than going back to the database for everything. Of
> course, in this case, it's important to use a "sticky session"
> clustering approach that works.
>
> REST is cool, but I don't know how we'd use pure REST to write, say,
> an online banking system. :)
>
> -- HTH, Ted
> <http://www.husted.com/ted/blog/>
>
>
> On Nov 29, 2007 12:22 AM, Jeromy Evans <je...@blueskyminds.com.au> wrote:
>> Gary Affonso wrote:
>>> What's wrong with the session?
>>>
>> There's nothing wrong with it in most -existing- webapps because it's
>> the most productive means to record state, but it's always been a
>> problem for clustered apps, has always been evil according to REST
>> purists and is becoming less popular as web developers move to
>> SOAUI/SOFEA architectures.
>>
>> David Van Couvering's blog provides a good example:
>> http://davidvancouvering.blogspot.com/2007/09/session-state-is-evil.html
>>
>> regards,
>> Jeromy Evans
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] session state (was Re: Wizard like Screens)
Posted by Ted Husted <hu...@apache.org>.
Just to emphasize what Jeromy is saying, the key words are "scalable"
and "cluster". In the case of an intranet application with a set user
base that won't be clustered, *not* using session could be evil,
since the alternatives tend to be more work to implement and maintain.
In physics, we have very different rules that apply for large-scale
and small-scale calculations. We need to keep in mind that the same
principle applies to web development. There are different rules for
large-scale and small-scale deployments.
Though, I do know large-scale deployments that do use session-state.
In fact, they use *a lot* of session state, because, in their case,
it's cheaper than going back to the database for everything. Of
course, in this case, it's important to use a "sticky session"
clustering approach that works.
REST is cool, but I don't know how we'd use pure REST to write, say,
an online banking system. :)
-- HTH, Ted
<http://www.husted.com/ted/blog/>
On Nov 29, 2007 12:22 AM, Jeromy Evans <je...@blueskyminds.com.au> wrote:
> Gary Affonso wrote:
> > What's wrong with the session?
> >
> There's nothing wrong with it in most -existing- webapps because it's
> the most productive means to record state, but it's always been a
> problem for clustered apps, has always been evil according to REST
> purists and is becoming less popular as web developers move to
> SOAUI/SOFEA architectures.
>
> David Van Couvering's blog provides a good example:
> http://davidvancouvering.blogspot.com/2007/09/session-state-is-evil.html
>
> regards,
> Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
[OT] session state (was Re: Wizard like Screens)
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Gary Affonso wrote:
> Tom Schneider wrote:
>> Both of those plugins, by default, would need the session to keep
>> track of
>> the state.
>
> Oh, duh. I didn't see that he wanted to avoid the session.
>
> What is up with that BTW? There seem to be quite a few posts lately
> from people wanting to do stuff and avoid the http session (or its
> struts2 wrapper).
>
> What's wrong with the session?
>
There's nothing wrong with it in most -existing- webapps because it's
the most productive means to record state, but it's always been a
problem for clustered apps, has always been evil according to REST
purists and is becoming less popular as web developers move to
SOAUI/SOFEA architectures.
David Van Couvering's blog provides a good example:
http://davidvancouvering.blogspot.com/2007/09/session-state-is-evil.html
regards,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Wizard like Screens
Posted by Gary Affonso <gl...@greywether.com>.
Tom Schneider wrote:
> Both of those plugins, by default, would need the session to keep track of
> the state.
Oh, duh. I didn't see that he wanted to avoid the session.
What is up with that BTW? There seem to be quite a few posts lately
from people wanting to do stuff and avoid the http session (or its
struts2 wrapper).
What's wrong with the session?
Yah, you gotta be careful with it...
* gotta be careful about memory consumption
* hibernate objects get detached from their hibernate sessions
* non-serializable objects eliminate session-save-across-restart
functionality in tomcat
... but if you use it sanely, it's an awesome tool. And it's a good
base upon which you can implement more granular scopes (as the scopes
plug-in does and as WebFlow allows the option for).
Did the session become evil somewhere along the way? Did I miss a memo?
- Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Wizard like Screens
Posted by Tom Schneider <sc...@gmail.com>.
Both of those plugins, by default, would need the session to keep track of
the state. The webflow plugin can be configured to serialize the state to a
hidden field, but there would be a lot of configuration and complication
just for 2 fields.
I would say your best bet is to have hidden fields that keep track of the
values you want to maintain. This will work well if the workflow is only 2
pages. If it's more than that, then hidden fields would become somewhat
tedious. In a multi-page workflow, the easiest solution would be to use the
scope plugin with session or conversion scope. Currently there is no
built-in support for simple workflows that don't use the session.
Gary Affonso wrote:
>
> My suggestion would be to checkout the scope plug-in or WebFlow and the
> WebFlow plug-in.
>
> - Gary
>
> Radha Krishna wrote:
>> Hi,
>>
>> I have a wizard like screen where i need to pass the selected values (2
>> text box) at first page to last page,last page to again first page.
>>
>> Can anyone tell me the best solution how could i achive this without
>> storing values in to Session?
>>
>> Thanks.
>>
>>
>> ---------------------------------
>> Never miss a thing. Make Yahoo your homepage.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Wizard-like-Screens-tf4862135.html#a13944234
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Wizard like Screens
Posted by Gary Affonso <gl...@greywether.com>.
My suggestion would be to checkout the scope plug-in or WebFlow and the
WebFlow plug-in.
- Gary
Radha Krishna wrote:
> Hi,
>
> I have a wizard like screen where i need to pass the selected values (2 text box) at first page to last page,last page to again first page.
>
> Can anyone tell me the best solution how could i achive this without storing values in to Session?
>
> Thanks.
>
>
> ---------------------------------
> Never miss a thing. Make Yahoo your homepage.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org