Alright, I'll try to explain what I'm doing with the relevant pages and why I'm doing things this way.
When a user logs into the site I'm creating, they have various options related to data entry into a mySQL server. The option I'm currently trying to implement lets the user enter the personal data for a participant in a survey into the database. The steps I've implemented to do that are as follows (all of the following pages are displayed in an iframe running inside of a main Display.jsp page for the site, to keep everything looking consistent):
1) User gets to a plain old HTML page called Survey.html. Nothing out of the ordinary here; the page just displays a basic form in an iframe. The form's target is the second page SurveyProcess.jsp.
2)SurveyProcess.jsp page doesn't do much other than define a few variables based on what the user entered for the participant's name, DOB, etc. It checks each field against what is expected (ie Dates are in proper form, the participant's ID is in the correct form, etc) and adds an error to the error vector that is created in the bean. If, once it's done processing the data, it doesn't find any errors, the page creates a temporary table in mySQL (named based on ('temp' + "participant's ID") and forwards to VerifySurvey.jsp. If it DOES find errors, it forwards to SurveyRetry.jsp. Both of these forwards are done with pageForward.context("target").
3) VerifySurvey.jsp creates a "display form" (it just displays data, and makes the user click "submit" to get the data into the actual database. Eventually there will be an option to further edit the data, but I need to figure out how to pre-fill forms correctly for that to be useful). The form targets VerifySurveySubmit.jsp, which calls the appropriate methods from SurveyBean to move the temp file into the actual database, and it also deletes the temp file. If the methods succeeded, everything forwards back to
Survey.html. If the ID is already in the database, it says so, and forwards back to Survey.html. If other errors resulted, it outputs them. The error output is mainly "just in case" right now, as SurveyProcess did enough that everything should be in the right form for mySQL to read.
4) SurveyRetry.jsp is basically a clone of Survey.html, but with an added area for errors (Survey.html's form is created in a table; I just added an extra column which holds any errors for each field in the form). Right now, the errors display perfectly (e.g. if there was an error with the ID the error message is displayed in the correct place for the ID) but the original data entered into the field does not. I want the form to display everything the way it was originally entered into Survey.html, so that the user doesn't have to re-enter all of the fields every time they input something wrong. The target of SurveyRetry.jsp is the same as Survey.html, so it keeps getting checked over until everything on it is in the right form.
I'm not very experienced at all with web development on this scale, and I've been going based on the Sun Java documentation and random JSP tutorials I've found online that are kind of doing the same thing I am. Needless to say, what I have so far results in a fairly fragmented understanding of JSP, so while I think my structure is fairly well put-together (at least for my uses; this basic structure is also going to be used for entering in survey data at some point), the implementation of the server requests and session data is not very well defined, and I'm sort of afraid to change what I have going right now without a clear idea of how to make it work in a manner more befitting the modern era (I'm pretty sure some of the tutorials I've been using were written in the late 90's). So, if any of you JSP experts could enlighten me as to how I should be keeping the data first entered into Survey.html persistent (whether to use <jsp:forward> tags or session.setAttribute() statements at some point, or some other technique), I would be very appreciative.
Appendix A) The bean that all of these pages use is called SurveyBean, and has a few methods for mySQL manipulation (so that my site actually generates useful data to stick in the database) as well as stores the current errors and various other miscellaneous "housekeeping" methods.
[ November 09, 2007: Message edited by: Sam Gardner ]