Re: About Action Form
ok, I get your point now, ^^ thank for help ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: About Action Form
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: About Action Form
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: About Action Form
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: About Action Form
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: About Action Form
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: About Action Form
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
About Action Form
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
