See below. Les Hartzman wrote: > > needArchitectureHelp wrote: > > > > > Using the JSP model for using a bean to store form data (i.e. use > > > <jsp:setProperty> to store form input fields - use <jsp:getProperty> to > > > retrieve data) - How does Java/server keep track of the beans from JSP to > > > JSP page? For example - I use 3 JSP pages to process one form - first JSP > > > page accept input - second JSP validate input (if invalid back to first > > > page) - third JSP update database. > > > > > > > [snip] > > > > > > > > > Is this the best way to validate (i.e. using beans)? Is there a better/easier >way? > > > > > > > I handle user input on a multi-page form the same way you are doing it. Where we >differ is in the final processing -- I use a servlet that calls an appropriate action >class method, > > depending on which action needs to be taken. This approach better separates >business logic and presentation logic (you are going to be tempted to combine them, >especially in the third > > page that stores the info into the database). It has been variously called the >"Model 2" architecture (named after what it was called in the JSP 0.92 >specification), or the JSP+servlets > > architecture, and has been extensively discussed on both the JSP-INTEREST and >SERVLET-INTEREST mailing lists. Check the archives for more information. > > > > Craig, > > I may be misunderstanding your response on input validation. Are you using 1 JSP to >pull the user input from the from, a 2nd one that calls beans to validate, and a >servlet-stored bean to process the data (assuming it validates properly)? > Let's take the simple case (single input page first), and I will describe what I do: * JSP page presents the form, with current values specified in a session-scoped bean. (The very first time in, the <jsp:useBean> declaration creates this bean with default values). * The JSP page includes client side JavaScript for the things you can detect client-side, but that is usually not sufficient to catch everything. * Form submit on this page goes to a servlet, which calls an appropriate action class (Model 2 architecture, see previous discussions on the list) that validates *all* of the input fields. (Why all? Because you cannot assume that your client is a browser that did the JavaScript validations -- it might be an app, or a browser with JavaScript turned off). * Besides validation, the action class also updates the session bean that represents the contents of this form with whatever the user actually typed, whether it is valid or not. This is useful if I have to go back with an error message, because the form can be filled out as the user last submitted it -- this behavior is expected by anyone used to GUI programs. * If the validation detects an error, it stores an error message bean as a request attribute, and forwards control back to the original JSP page that presents the form again (with the most recently input values) plus an error message. The error message is only displayed if the request bean exists, which will be true only if the validation processing above put it there. * If the validation does not detect an error, the action class goes ahead and does whatever database updates are appropriate. If there's a database problem, it sends back an error message (the same way it would have a validation error) -- otherwise, control is forwarded to whatever JSP page is appropriate for the next interaction with the user. If you have a multi-page input form (think of the wizard that helps you install most Windows apps, with forwards and backwards buttons on it), I use basically the same technique. All of the fields for the entire form are represented in a single bean (you might change your mind later about which fields go on which pages, but you don't have to change the bean at all), and the "next" and "previous" links point at the appropriate JSP pages. Only the final submit button goes to the servlet, as above. > > Is there a reason that within 1 page you wouldn't collect the data and have beans >validate the data? > IMHO (and opinions differ here, but my opinion is strongly felt), it is a mistake to submit to a JSP page. JSP pages should be used for presentation logic *only*. If you use JSP pages for business logic as well, you're going to find it incredibly difficult to avoid intermixing business logic and presentation logic in the page, which makes the inevitable changes that come later much more difficult to implement. It also limits your flexibility in a more important way -- what happens if you want to provide more than one "presentation" of the same underlying business logic? If the business logic is intermixed, and you have three alternative presentations, you must now maintain that business logic in three places instead of one. I prefer using a Model-View-Controller (MVC) design for my apps, where the JavaBeans you store as session-scope or request-scope attributes represent the Model, the JSP pages represent the View, and the servlet represents the Controller. In other posts, I and others have described how to create a single servlet per web application to play this role, which is set up to map an incoming request URL to a particular action class, based on a mapping table that is configured at runtime (no recompiles to add new actions). There's been *lots* of discussion of this architecture on the JSP-INTEREST and SERVLET-INTEREST mailing lists over the last few months. I'd suggest reviewing the archives for more background info. > > Thanks. > > Les > Craig McClanahan =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". FAQs on JSP can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html
