About Action Form

[Koon Yue Lam <ki...@gmail.com>]

Hi, suppose I have 2 actions which each has its own action form
A1 will have F1
A2 will have F2

and we have JSP1, JSP2 and JSP3

it is like a 2 steps wizard, 
user first access JSP1 and when submit, A1 is executed and populate
F1, it then forward to JSP2

user will select some data in JSP2 and when submit, A2 is executed and
populate F2

The question is the data need to populate F2 is determined by what
user select on F1, but only one action form can be associated to
action. How do A2 know what user has selected??

any help will be appreciated

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: About Action Form

[Koon Yue Lam <ki...@gmail.com>]

ok, I get your point now, ^^

thank for help !

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: About Action Form

[Michael McGrady <mi...@michaelmcgrady.com>]

Hi, Lam,

I assume you are asking me what I was talking about.  (When addressing 
something said, it is a good idea to leave that somewhere in your 
reply.)  Anyhow, if you are asking about what I said, here is a bit.

Usually there are a given number of options discussed for maintaining 
state with a user.  You are familiar with them and the issues, I assume, 
from cookies, hidden parameters, session storage, database storage, 
etc.  I have found for my uses that an application level manager for 
data is better than any of the standard solutions for most of my 
situations.  You have to build the manager to do what you want, which 
usually will have to be multithreaded.  Some of my manager parts use 
things like Doug Lea's worker threads and are triggered by events, such 
as incoming requests.  Some of my manager uses the Java Timer with 
subclasses of TimerTask, which are also multithreaded and are triggered 
my timed monitoring processes.  The variety and details is up to you.  
That is what I like to do, in any event, rather than just rely on 
session management as coded by the server component, etc.

Michael McGrady. 

Koon Yue Lam wrote:

>thanks to Frank !
>and Michael:
>what u mean an application level multi-threaded program? is it a
>background deamon / process to store data that likely to be store by
>session ?
>
>---------------------------------------------------------------------
>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: About Action Form

[Koon Yue Lam <ki...@gmail.com>]

thanks to Frank !
and Michael:
what u mean an application level multi-threaded program? is it a
background deamon / process to store data that likely to be store by
session ?

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: About Action Form

[Michael McGrady <mi...@michaelmcgrady.com>]

Frank is definitely right.  You will have to decide.  You can store data 
in a database too.  If you have a situation where the data is 
particularly session oriented, then storing in the session makes sense.  
However, remember the odd things that can happen with things like 
popups, frames, etc.  I personally prefer to use an application level 
multithreaded program that does this stuff, relying on my own algorithms 
and not upon session management in the container. 

Frank W. Zammetti wrote:

> Session is probably the way to go.  For things like this, i.e., data 
> that is transient on the whole but needs to persists across a number 
> of requests, session is probably the right choice.
>
> Why WOULDN'T it be the right choice?  If your storing a lot of data, 
> session can become a problem, especially if you might deploy to a 
> distributed environment.  Second, if you expect a very large number of 
> requests, you may find server resources being chewed up more than 
> you'd like and performance might ultimately suffer.  Also, if you need 
> the capability of saving the steps of the wizard for later, you'll 
> need a more permanent persistence mechanism.  These are just some of 
> the concerns.
>
> All that being said, from what you describe, I'm thinking session 
> without hesitation.  Not much data, your entire process takes a couple 
> of steps then some final result (which may be more permanently 
> persisted, I don't know)... Session coding will be very easy, and 
> unless your going to have a huge load, there shouldn't be any 
> problem.  Only you know all the details though, so you'll have to make 
> the real determination.
>



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: About Action Form

["Frank W. Zammetti" <fz...@omnytex.com>]

Session is probably the way to go.  For things like this, i.e., data 
that is transient on the whole but needs to persists across a number of 
requests, session is probably the right choice.

Why WOULDN'T it be the right choice?  If your storing a lot of data, 
session can become a problem, especially if you might deploy to a 
distributed environment.  Second, if you expect a very large number of 
requests, you may find server resources being chewed up more than you'd 
like and performance might ultimately suffer.  Also, if you need the 
capability of saving the steps of the wizard for later, you'll need a 
more permanent persistence mechanism.  These are just some of the concerns.

All that being said, from what you describe, I'm thinking session 
without hesitation.  Not much data, your entire process takes a couple 
of steps then some final result (which may be more permanently 
persisted, I don't know)... Session coding will be very easy, and unless 
your going to have a huge load, there shouldn't be any problem.  Only 
you know all the details though, so you'll have to make the real 
determination.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

Koon Yue Lam wrote:
> oh, so I need some way to store data in the respond object
> I know session can be help, is it a right way to do?
> It is not very big object but it would be an array of String (which
> contains user's multiple selection)
> 
> thanks for your help, ^^
> 
> ---------------------------------------------------------------------
> 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: About Action Form

[Koon Yue Lam <ki...@gmail.com>]

oh, so I need some way to store data in the respond object
I know session can be help, is it a right way to do?
It is not very big object but it would be an array of String (which
contains user's multiple selection)

thanks for your help, ^^

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: About Action Form

[Michael McGrady <mi...@michaelmcgrady.com>]

The answer can be determined by thinking it through.  Start with where 
the data is and where it goes.  You do not say if data prepopulates a 
form, so I will assume it does not. 

JSP1 has some data which is submitted and shows up in F1 and maybe A1.  
Right?  There it is.  Your data.  All of it and that is it.  If the 
foward to JSP2 does not somehow save that data, then .... the data will 
be gone.  So, if you need it, you need to save it somehow.  There are 
lots of ways to do that.  So, you get to JSP2 and either have data saved 
or not.  If not, not.  Is so, so.  This is exactly all there is to it in 
an important way.  When JSP2 is submitted the data is sent to F2 and 
maybe A2.  If JSP2 did not save any previous data in the response 
object, and nothing else did too.  All the data left, as we reach good 
old A2 which forwards to JSP3.  Now if no data from A2 is saved, old 
JSP3 doesn't get any.  That's all there is to it. 

Michael

Koon Yue Lam wrote:

>Hi, suppose I have 2 actions which each has its own action form
>A1 will have F1
>A2 will have F2
>
>and we have JSP1, JSP2 and JSP3
>
>it is like a 2 steps wizard, 
>user first access JSP1 and when submit, A1 is executed and populate
>F1, it then forward to JSP2
>
>user will select some data in JSP2 and when submit, A2 is executed and
>populate F2
>
>The question is the data need to populate F2 is determined by what
>user select on F1, but only one action form can be associated to
>action. How do A2 know what user has selected??
>
>any help will be appreciated
>
>---------------------------------------------------------------------
>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