Web Hosting Java, JSP, Tomcat 6, J2EE, Servlets, Struts, Jboss

JavaSercer Pages There (Mysql webhost) are at least two ways

JavaSercer Pages There are at least two ways to deal with this. In Example 10.5, the action is followed by a scriptlet checking that the request for this page is a POST request. If not, it redirects to the main page without processing the request. This is the easiest way to deal with the problem, but it also means that the user will have to retype the message again. The chance that a session times out before a form is submitted is small, so in most cases this is not a big deal. It’s therefore the solution I recommend. If you absolutely must find a way to not lose the POST parameters when a session times out, here is a brief outline of a solution: 1. Modify the action to send a URL in the origURL parameter suitable for use as a forward URL, as opposed to a redirect URL, if the page is invoked with a POST request. A forward URL must be relative to the servlet context path, while a redirect URL should be absolute. 2. Use a scriptlet in the login page to save all POST parameter values as hidden fields in the form, along with a hidden field that tells if the original request was a GET or a POST request. 3. In the authentication page, forward to the originally requested URL if the method was a POST and redirect only if it was a GET. The authentication page is always invoked as a POST request. A forward is just a way to let another page continue to process the same request, so the originally requested page is invoked with a POST request as expected, along with all the originally submitted parameters saved as hidden fields in the login page. Depending on your application, you may also need to save session data as hidden fields in the page that submits the POST request, so that the requested page doesn’t have to rely on session information. But this leads to another problem. What if someone other than the user who filled out the form comes along and submits it? Information will then be updated on the server with information submitted by a user that’s no longer logged in. One way out of this is to save information about the current user as a hidden field in the form that sends the POST request, and let the authentication page compare this information with the new user’s information. If they don’t match, the client can be redirected to the main application page instead of forwarded to the originally requested URL. As you can see, there are a number of things to think about. Whether or not it makes sense to address all the issues depends on the application. My general advice is to keep it simple and stick to the first solution unless your application warrants a more complex approach. 10.2.5 Updating the User Profile The updateprofile.jsp page, used if the user makes new project selections in the main page and clicks Update Profile, is also invoked through the POST method. It follows the same approach as the storemsg.jsp page, and is shown in Example 10.6. But what’s interesting about the updateprofile.jsp page is that it shows how to replace multirow data for a user, and is an instance of when you need to care about transactions. Example 10.6. Updating Multiple Database Rows (updateprofile.jsp) <%@ page language="java" %> <%@ taglib uri="/orataglib" prefix="ora" %> <%-- Verify that the user is logged in --%> <%-- Verify that it's a POST method --%> <% if (!request.getMethod( ).equals("POST")) { %> <% } %> <%-- Make the bean available for scripting elements --%> <%-- Update the project list in the bean --%>  
You guys and gals are the best bang for the buck, and I've looked around a lot!"

Yours for over 3 years,
~Michael Matthews
top100download.us