I am needing a little bit of logic information on how to call a jsp page from itself. Basically, I am going to be doing a postback to the same page I am on. What I need to know is how to ignor certain parameters the first time the page is loaded but then go ahead and do something with parameters when the page is called from itself. Thanks. [ July 27, 2003: Message edited by: Gregg Bolinger ]
I use this pattern all the time, and usually it is easiest to use 'GET' the first time when simply displaying the page, then 'POST' the data back to itself for processing. It's cleaner using MVC and managing thos in the controller, but has been done occesionally in JSPs too. Dave
How is it easier in the controller? Either way, the called JSP page must determine if there is anything extra to view, right? So if I call jo.jsp the first time, and the next time I call joServlet which uses jo.jsp as it's view also, there is still some logic in the JSP page that handles this, no? This is what I am wanting to know.
But the point of my question is not "if the page needs to be shown again". The point is I am doing a postback. So that page is being shown. Period. Ok, so let me adjust my requirement. I have form. This form page is called and the first time it is called, the form is empty. But let's say you fill in the employee ID # field and click submit. A servlet is called that queries a database and returns the the rest of the fields to the same jsp page. So now, the page is called again from the servlet but this time, all the fields need to have data in them. Same Form, first time no data, second time, data. What logic is performed to determine whether or not there is data in the bean? And how do you handle that logic in the JSP page?
Firstly, I don't tend to use beans, but we create a object that doesn't hold any data (or empty rather than null Strings) and then always assume that there is valid data to display. If we use MVC, the JSP always grabs whatever object is available and populates with data from it. Controller:
Nothing too earth shattering. (I never been a fan of beans, no pun intended)
Hi Greg and David, U both are creating a mountain out of a mole hill. Greg from what i can understand is that u need to resubmit the form onto the same page, am i right ??
Okie, assume we have a page A.jsp ( Our page which needs to come back to itself on submit ) and we have the servlet B, which gets called when A.jsp is submitted. I simply put a hidden form field on A.jsp, say bringback. The first time i come on A.jsp i have bringback as null. When i submit A.jsp, it checks whether the data submitted has relative data in database. If it does get data from the database, in the servlet i write request.setAttribute("bringback","1"); and use a RequestDispatcher and push back the request to A.jsp. On A.jsp, check request.getAttribute("bringback") == null. If it is not null means we have come on this page for the second time, load the data.
Am i sounding clear or have i confused u even more??
But why start managing things like hidden fields when they aren't even required? Your hidden field doesn't accomplish anything that can't be accomplished using the GET/POST, with the added advantage that perdorming functionality based on GET/POST conforms to what GET and POST are supposed to get used for. ie GET to get data, POST to send data.
Joined: Oct 04, 2001
David, Now u r confusing me , as far as i know, doget and dopost perform the same action except they support different sizes of data. Whats the purpose of using a hidden field is, The first time i come on A.jsp, we have not gone to servlet B as yet. At this point of time, how am i to know that the page is getting called for the first time ?? So,the first time the page shows up, the field will have a null value, however the second time the page shows up ( After request passes thru servlet B ) we know that we have to be in edit mode rather than be in new page mode.
Oddly enough, the debate over this assumed simple question has lured me a bit closer to another technology. Why is something so commonly done in most all Web Apps still obviously debatable when doing it with J2EE?
Gregg, I usually prefer to do this in a controller servlet as well, but...I often do exactly what you are talking about for test pages, utility pages, and even some basic admin pages. The easiest way I have found is to simply add a name attribute to your submit button. Then you need a scriptlet to check for that name in the parameters. It will only exist if the form was submitted by pressing that button, otherwise the parameter will be null. No extra hidden fields either. That's always worked for me.
What would be nice is if all JSP pages had an associated Servlet with them. Ok, I know JSP pages get turned into servlets. But as JSP is right now, as I understand it, if you want to request a servlet, you call the servlet, if you want to request a JSP page you call a JSP page. Why not ALWAYS call the JSP page, and then let it have it's own servlet to do the work? Well, like ASP.NET works with CodeBehind. I really like that methodology. So instead of have scriptlets in the code, have a CodeBehind page that is all JAVA. I guess you could do that and just call a Servlet from the JSP page being called? I might try that and see how that works.
Originally posted by Deepak Acharya: Now u r confusing me, as far as i know, doget and dopost perform the same action except they support different sizes of data.
Partly true, there are bigger differences to do with security and (sometimes more importantly) resposibility, but we're heading away from the original discussion. You can still use "POST".equals( response.getMethod() ) in place of an input field that doesn't do anything else.
Originally posted by Jay Dellinger: The easiest way I have found is to simply add a name attribute to your submit button.
In a purely JSP solution, I usually do either this or use getMethod as above, but in practice we never deploy a JSP without a Servlet anymore, even if the Servlet doesn't do anything real.