Good day. Having read about Model 2 architecture I got confused about some points.
For example my controller servlet url-pattern is '*.perform'.
How do I access the database and put the bean into the session if my jsp url does not correspond the servlet url-pattern?
If I've done the action, why do I use forward? The url remains the same 'actionName.perform'
How should be the app designed for the servlet to process every page and forward to the corresponding JSP without processing it again?
The point of a front controller is that it intercepts all requests. You should never send a request to a JSP directly. Always to some *.perform URL. All your links and forms must poiunt to an *.perform URL.
The forward gives the control, at server-side to another resource. Once the controller servlet has finished its job, it gives the control to the JSP, which generates the markup. This all happens at server-side, and the browser knows nothing about this. It's absolutely normal for the URL to remain the same.
See 1. I don't understand what you mean by "without processing it again", though.
Related
I've a web application that uses FreeMarker templates and tiles to do the View job in the MVC world. So upon my request to the application, say /load.do I would like to introduce an intermediate page that will have a loader icon just to indicate the page is being loaded on the subsequent request, which is not known to the user.
So ultimately what I'm achieving is a better user experience and also if used within framework (the iFrames) this comes handy to show the loader icon when there is a new request that is happening.
Can someone point me to the right method I can use here ?
This is possible using spring mvc.
You need to create something like a WaitController. On user submit , this controller will be called. This can trigger your original request in background and take a reference(UUID) for the call and will render a wait page having the reference id of the original request set in model. Wait page can either trigger immediately the main controller using reference id or can poll the reference id on regular intervals or use web socket to know the availability of results. Once results are ready, it should redirect user to the actual result page.
Is there any way to redirect to spring controller from a jsp page with custom headers.
I don't want to do a GET/POST request using jquery ajax.
I want to do a complete redirect to another page..
Please help.
Maybe. Note: Changing the headers isn't possible if your JSP has written something, so the "redirection" needs to be the first thing on the page.
What you can do is use jsp:include to include another page. If your JSP doesn't output anything else, that will work very much like a redirect. You can use
<%if(...){%>
<jsp:include ...>
<%}else{%>
...no redirect...
<%}%>`
to create alternatives to make sure nothing is written to the output.
The next step is then to get the controller bean from Spring and call the methods directly. Note that you'll have to replicate a bunch of Spring's conveniences (like converting the result of the method into bytes sent to the browser). But Spring isn't doing any magic; eventually everything is Java code somewhere which you just have to call manually.
In OmniFaces, the FullAjaxExceptionHandler, after having found the right error page to use, calls the JSF runtime to build the view and render it instead of the page that includes the AJAX call.
Why this? IMHO it would be simpler to just perform a ExternalContext#redirect()? Are there specific reasons to do this?
We are writing our own ExceptionHandler based on FullAjaxExceptionHandler and wanted to understand the reason behind this design.
The primary goal of the FullAjaxExceptionHandler is to let exceptions during ajax requests to behave exactly the same as exceptions during non-ajax requests. The developer must be able to reuse the error pages across both conditions without worrying about the condition while implementing the error pages.
A redirect isn't part of the normal flow during non-ajax requests. The default <error-page> mechanism in web.xml performs a forward to display the error page, not a redirect. If a redirect was performed, all error page request attributes such as javax.servlet.error.exception would get lost and render as null. Moreover, normal practice is to place error pages in /WEB-INF to prevent endusers from being able to directly access (and bookmark and share) them. A redirect would require them to be publicly accessible, which indicates a major design problem (is the intented target page actually a real error page?).
If you really need to perform a redirect to/from your error page, either homegrow a custom exception handler which explicitly invokes ExternalContext#redirect() and doesn't utilize web.xml <error-page> mechanism, or add a <meta http-equiv="refresh" ...> to the HTML head of the error page in question (example here).
In case you actually intended to redirect to some login page when a ViewExpiredException occurs, then you should realize that there's a big difference between the cases of "User is not logged in" and "Session/view is expired". For the former, you should not be catching ViewExpiredException at all, but use a simple servlet filter which checks if the user is logged in and redirect accordingly, long before the FacesServlet is invoked. A normal authentication framework (JAAS, Shiro, Spring Security, etc) also works that way.
See also:
What is the good approach to forward the exception from servlets to a jsp page?
What is the difference between redirect and navigation/forward and when to use what?
Why use a JSF ExceptionHandlerFactory instead of <error-page> redirection?
Check if session exists JSF
Authorization redirect on session expiration does not work on submitting a JSF form, page stays the same
I am new to JSP/Servlets/MVC and am writing a JSP page (using Servlets and MVC pattern) that displays information about recipies, and want the ability for users to "comment" on it too.
So for the Servlet, on doGet(), it grabs all the required info into a Model POJO and forwards the request on to a JSP View for rendering. That is working just fine.
I'd like the "comment" part to be a separate JSP, so on the RecipeView.jsp I can use to separate these views out. So I've made that, but am now a little stuck. The form in the CommentOnRecipe.jsp posts to a CommentAction servlet that handles the recording of the comment just fine. So when I reload the Recipe page, I can see the comment I just made.
I'd like to:
Reload the page automatically after commenting (no AJAX for now)
Block the user from making more than one comment on each Recipe over a 1 day timeframe (via a Cookie). So I store a cookie indicating the product ID whenever the user makes a comment, so we can check this later? How would it work in a MVC context?
Show a message to the user that they have already commented on the Recipe when they visit one
which they have commented on
I'm confused about using beans/including JSPs etc on how to achieve this.
I know in ASP.NET land, it would be a UseControl that I would place on a page, or in ASP.NET MVC, it would be a PartialView of some sort. I'm just confused with the way this works in a JSP/Servlets/MVC context.
you can use response.sendRedirect() or forward APIs in javax.servlet to redirect to a new page or refresh the same page (redirect to the same page/path so that the beans/data gets refreshed)
about restricting to one comment per day - yes you can use cookie but the problem is that user might use another browser type (chrome, FF, Safari) and will be able to make multiple comments.
Ideally you should store the lastCommentTime in the model/persistent store and tie it to the user information - this way your model object can expose an API that checks the last comment time and returns true/false depending on whether user can comment or not.
You can use this API in your servlet/JSP to show/hide the comment button, for example and also show a message
I'm using a Webphere server. I am performing a file upload through a servlet using the Apache FileUpload methods.
I attach a listener to this FileUpload which updates a "percentage" field denoting what percentage of the request has been processed. The request gets directed to an iframe (form's target is an iframe) so that the page that fired the request doesn't have to wait for the response to complete and therefore it won't show the user just a blank page. I add a reference to the progress listener to the session as well.
From the JSP page as soon as I fire the submit on the form, after 1 second and then every second I fire an ajax request which goes to a servlet which looks up the ProgressListener and responds with the percentage field. The process works fine, but on Websphere sometimes this Ajax request can take up to 30 seconds to complete! I tested the same thing on a simple Tomcat server and there the request/response comes out within a second.
What could be wrong? Is it a server setting?
Thank you,
Edit: The code inside the servlet that gets the percentage from the session runs as soon as the request is made. The bottleneck seems to be in delivering the request back to the client browser.
Do you have websphere configured to compile and cache the jsp page, or is it recompiling each time?
You may want to use AOP, either AspectJ or Spring, or a profiler, to see what is going on with the ajax call, so that you can monitor without changing any code in the jsp page.
The profiler may be a better starting point, just so you can look globally at what is going on, then use aspects to monitor in a fine-grained fashion and decide where the bottleneck is.
You could also see if precompiling the jsp pages will help. This tutorial should be useful:
http://publib.boulder.ibm.com/infocenter/wchelp/v6r0m0/index.jsp?topic=/com.ibm.commerce.samples.doc/tutorial/tdedeployjsp.htm