Stéphane Zuckerman wrote:
If you are doing this type of thing, you should be using Swing, or some other thick client that you can actually program using an API.Hello,
I am to write JSP pages with a form that has some items (lists, or checkboxes) that depend on previous choices from the same form.
So here I have two choices basically :
1°) Load all the information that is possibly needed for a given page, hide it, and only show what is relevant with some javascript. For instance, If I select some "foo" option in a list, then below in the form, a second list is loaded with "bar1", "bar2", "bar3é ... options, which are related to the "foo" option.
Drawback : if there are lots of possible options, lots of texts, and lots of users, this might be too heavy a solution.
2°) When I select "foo", then some javascript reloads the page (it does a post) with the "foo" argument, and the rest of the JSP is loaded. This is the way I'd like to take, since some informations mustn't be in the clear uselessly.
My problem is that I don't really know where to start and how to do such a thing (do I use the same action through different stages ? Or do I put a lot of little actions that lead to a single big one ?)
I would use the same action through different stages. I don't have a tool to recommend for this or anything. I am close to defining some coding patterns for it, but still I'm doing it slightly differently each time I do it, and I've not done it in a Struts app, but have a few times using my own request handlers. You are implementing a state machine, but that doesn't mean it has to be complicated. It involves 1) keeping track of the user's current command, and possibly his entire command stack (aka "wizard"), though often this can be implied by the current command, and 2) keeping track of any properties accumulated and modified during execution of each of those commands. You can do this tracking via embedded link/form parameters or HttpSession attributes or some combination of each (as always). For each post, I typically write to the cache until I reach the commit point, and then I write to the database and dump the cache. For each response I might read from the database or the cache or some combination of both. You have to remember with this approach to clean up session variables when the user "leaves" (finished or not) and to keep page loading times down (as always).
Good luck, Erik
I hope I've been clear enough (I have difficulties finding the right phrases to express my problem), and that someone will be able to help me.
Stéphane
--------------------------------------------------------------------- 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]
