I'd like to accomplish the following:
I have a form represented in a JSP – let's call this input.jsp. This form submits to a servlet which will create objects in a DB – lets call this CreateServlet. When the form is successfully submitted, the servlet should direct the user back to input.jsp and display a success message. When validation fails, it should redirect back to input.jsp, display an error message, retain the input values.
I can think of a few options:
On validation failure I can use a RequestDispatcher to perform a forward to input.jsp. This would allow me to easily display the validation errors and input parameters from the form. However, I know that a forward should not be used in the case of performing an edit operation, so when the request is successful I should not do a forward and should do a redirect instead. The problem with a redirect is that I can't set attributes as easily unless I pass it in the URL, e.g. input.jsp?success=true.
I can store validation messages, success messages, and input values in the session, and always perform a redirect. After the JSP has displayed the page then it can remove these attributes from the session.
I am using plain servlets and JSP and not any framework like Struts. What is the recommended practice in this case?
i will choose second option if i were you. My reason :
Make it an object to encapsulate all input in that form. it will
easier to maintain if i need to add attribute to the form.
It more secure because your url will clean from attributes.
It will very easy if you used framework like struts. Everything will be handled by them.
Related
I am currently learning JSF and was rather amazed and puzzled when I realized that whenever we use <h:form>, the standard behavior of JSF is to always show me the URL of the previous page in the browser, as opposed to the URL of the current page.
I understand that this has to do with the way JSF always posts a form to the same page and then just renders whatever page the controller gives it back to the browser which doesn't know the page location has changed.
It seems like JSF has been around for long enough that there must be a clean, solid way to deal with this. If so, would you mind sharing?
I have found various workarounds, but sadly nothing that seems like a real solid solution.
Simply accept that the URL is misleading.
Append "?faces-redirect=true" to the return value of every bean's action and then
figure out how to replace #RequestScoped with something else (Flash Scopes, CDI conversation, #SessionScoped, ...).
accept to have two HTTP round trips for every user action.
Use some method (e.g. 3rd party library or custom code) to hide the page name in the URL, always using the same generic URL for every page.
If "?faces-redirect=true" is as good as it gets, is there a way do configure an entire application to treat all requests this way?
Indeed, JSF as being a form based application targeted MVC framework submits the POST form to the very same URL as where the page with the <h:form> is been requested form. You can confirm it by looking at the <form action> URL of the generated HTML output. This is in web development terms characterized as postback. A navigation on a postback does by default not cause a new request to the new URL, but instead loads the target page as content of the response. This is indeed confusing when you merely want page-to-page navigation.
Generally, the right approach as to navigation/redirection depends on the business requirements and the idempotence (read: "bookmarkability") of the request (note: for concrete code examples, see the "See also" links below).
If the request is idempotent, just use a GET form/link instead of POST form (i.e. use <a>, <form>, <h:link> or <h:button> instead of <h:form> and <h:commandXxx>).
For example, page-to-page navigation, Google-like search form, etc.
If the request is non-idempotent, just show results conditionally in the same view (i.e. return null or void from action method and make use of e.g. <h:message(s)> and/or rendered).
For example, in-page data entry/edit, multi-step wizard, modal dialog, confirmation form, etc.
If the request is non-idempotent, but the target page is idempotent, just send a redirect after POST (i.e. return outcome with ?faces-redirect=true from action method, or manually invoke ExternalContext#redirect(), or put <redirect/> in legacy XML navigation case).
For example, showing list of all data after successful editing, redirect after login, etc.
Note that pure page-to-page navigation is usually idempotent and this is where many JSF starters fail by abusing command links/buttons for that and then complain afterwards that URLs don't change. Also note that navigation cases are very rarely used in real world applications which are developed with respect to SEO/UX and this is where many JSF tutorials fail by letting the readers believe otherwise.
Also note that using POST is absolutely not "more secure" than GET because the request parameters aren't immediately visible in URL. They are still visible in HTTP request body and still manipulatable. So there's absolutely no reason to prefer POST for idempotent requests for the sake of "security". The real security is in using HTTPS instead of HTTP and checking in business service methods if currently logged-in user is allowed to query entity X, or to manipulate entity X, etc. A decent security framework offers annotations for this.
See also:
What is the difference between redirect and navigation/forward and when to use what?
JSF implicit vs. explicit navigation
What URL to use to link / navigate to other JSF pages
Bookmarkability via View Parameters feature
What can <f:metadata>, <f:viewParam> and <f:viewAction> be used for?
When should I use h:outputLink instead of h:commandLink?
Creating master-detail pages for entities, how to link them and which bean scope to choose
Retaining GET request query string parameters on JSF form submit
Pass an object between #ViewScoped beans without using GET params
I have a jsp say index.jsp it has a form and users enter details in it.I retrieve entered details using one.servlet and I validate those entered details.
Next I have to pass those values to another jsp say results.jsp which will dispaly the results in web page and asks for confirmation.At this point i want to know whether its a good practice to use session or setattribute?
Further result.jsp will send these details to another servlet called two.servlet where it will store those values in database.
So i want to know whether using session will help me to complete my task
The most common pattern is as follow :
[ a servlet prepares eventually data for the JSP containing the form ]
a JSP displays the form
a servlet takes the element from the form processes them and validates the input
if input is not acceptable forward back to first JSP
if input is acceptable, saves to database and redirects(*) to another page
If you want to add a confirmation phase, you should put it in the middle :
first JSP diplays the form
validation servlet validates the input and if Ok forward to a confirmation JSP
confirmation JSP displays data and a very simple form (Ok/Cancel)
final servlet take the result of the second form, saves the data in database and redirects as for the simple case.
The hard part in this second pattern is that you have to pass the input data to the final servlet. Session is an option, but you must consistently remove stale data from the session if the user takes any other action, for example passes an url to another part of the application directly from the URL bar (or from its favorites). Even if it uses more bandwidth, I prefere pass all relevant data in hidden fields.
As it is more complex, and after all the user has first to click on a submit button, the confirmation phase is often omitted. I you really need that, you could look at dedicated frameworks such as Spring WebFlow.
But I must admit all that is just the way I like ...
(*) this POST redirect GET pattern avoids that the browser asks the user if he wants to send again data when he presses the back arrow
I can understand your problem but i think you don't need two separate servlets(one for validation and another for saving) instead after doing your validation you can save it on db and then you could show the result in result.jsp via session or query strings
I have a struts action flow(struts-1.x framework), which, when executes, the action class ActionFlowActionUnit1.java sets a String variable varName to request using the code
request.setAttribute("varNameFromRequest", varName);
and the flow finally leads to the loading of a jsp Page1.jsp.
Now, Page1.jsp contains a button, which, when clicked, initiates a new struts action flow, which has the action class ActionFlowActionUnit2.java. In this class, I want to use the varName which I had set in request using request.getAttribute().
How can I do it WITHOUT USING SESSION?
Technically, I'm not sure if achieving this using requestis possible, because, triggering a new struts-action will lose all other information in the request that was previously set (if I'm correct).
I couldn't get anything from Google.
As you say, it is not feasible technically as you want it (every http request from the browser creates a new HttpServletRequest object)
You have 2 options:
Using the Session, which you want to avoid as far as I understand
Bring back and forth some parameter into every successive request with the value you would like to keep.
The second option would mean to store some parameter inside your Page1.jsp <form> with the variable you need your second action to receive, and then rinse and repeat. This is a pure html form solution.
If you are implementing a complex flow, this looks a fair case to have a look at Spring Webflow. There you can manage flow-level variables, which are stored at a "different" scope than request or session, and looks exactly what you want.
http://projects.spring.io/spring-webflow/
We pull data from server and for that If we are using Struts, then we can pull either by submitting a page which MVC Architecture or we cam make an AJAX call but conventions is of using forms and render response but we also face challenges to give rich user experience, so we compromise convention and start using excessive AJAX, so how we should make balance between two?
I personally think that AJAX should be used for displays updates and form submissions should be done via a page reload. Reasoning?
When submitting forms, you are telling the application to do something. Users tend to want to feel that it was done. When a page doesn't reload, users are often left wondering "Did that work?". Then they have to check to make sure what they did was right.
On the other hand, when you are displaying a chart or something, and the user says to "display 2011 data....now 2012 data" for instance, they aren't "doing" something (creating new entities, sending emails, etc). So AJAX can provide a nice user interface in this case. Page reloads would be annoying here.
In conclusion, I think form submission should be done via page reloads (let the user see it working), whereas display updates should use AJAX (prevent annoying page reloads).
Of course, this is a preference thing. Some of my company's applications use AJAX all over. But those are the applications that are the most difficult to maintain and debug. ;)
Regular old HTML form submission and fancy ajax forms are not mutually exclusive.
First, make the plain HTML form work correctly. Then, add javascript to hijack the form and send an ajax request.
The controller and model don't care if the user's browser supports (or has enabled) javascript. The rendered view is decided by whether the call was made with javascript or a simple form submission. This is one of the strengths of the MVC pattern, not a constraint.
I think that the choice between the two is somewhat intrinsic:
a form submission is synchronous and it reloads the page.
an ajax call is asynchronous and it does not reload the page.
If a certain action will change a lot of UI elements or needs to poll a lot of data to be rendered, I would go with form submission. On the other hand, if a certain action is used for simple actions, like populating a select box or improving user experience, then I would go for an AJAX call.
There is nothing avoiding you to use as many ajax calls or form submissions as you need, so in the end is up to you.
In this day and age, there is virtually no case to use the old standard HTML form submission method (other than pure nostalgia, or perhaps not knowing).
The <form> tags themselves can still be useful if you want to take advantage of the .serialize() function (which grabs all name-data pairs within the form into a query string), but other than that we don't need to use <form> tags at all these days.
Using AJAX, the developer has more control over the entire process, in a more condensed code base. But more importantly, we just don't do things that way anymore.
Consider:
(Old Style - Forms) When an HTML form submits: (a) it gathers the form field name= attribute values (these become the defacto variable names) (b) together with user-entered data in the form fields (which become the variable values), and posts these data-pairs to a PHP file (as specified in the action= attribute on the form tag). THEN, the page changes to that other page, causing a noticeable refresh of the screen and loss of all previously inputted user data. Even using the trick action="", wherein the form data is posted back to the same page it started from, the page is still reset/refreshed.
(New Style) Exactly the same process can easily be programmed using javascript/jQuery - except that the page does not refresh. All previously entered user data/text can remain undisturbed.
Back to your question:
With the old-style HTML form submission, the page changes - so if you want to do field validation you use javascript/jQuery to cut into the submit process, thus:
$('myform#btnSubmit').click(function(){
var some_fields_failed = false;
//check form field values here, set: some_fields_failed = true
if (some_fields_failed){
return false; //halts the HTML Form Submit process and returns control to the user
}
});
in which case you already are using most of the AJAX construct that would replace the HTML form submission process.
This simple introduction to AJAX provides some compelling reasons to use AJAX instead of the old-style HTML Form Submission process:
AJAX is a developer's dream, because you can:
Update a web page without reloading the page
Request data from a server - after the page has loaded
Receive data from a server - after the page has loaded
Send data to a server - in the background
Note that you can write ajax code in pure javascript, but until very recently it was considerably simpler (much less typing, more consistent) to use the jQuery (javascript) library. Hence, all examples above use jQuery. To include jQuery in your project, it is only necessary to include a reference to the jQuery library:
<head>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.2.4/jquery.min.js"></script>
</head>
StackOverflow maven, Schabse Laks, created a simple jQuery tutorial that is worth stepping through (IMPORTANT: Use Down Arrow to step through the pages)
If you have errors between submissions of data the only forms method you could check on the server. On the other hand if you make Ajax calls you could check that errors on the client side. So, out of this different technologies of transmitting data we could follow a decision that they serve different purposes.
When sending a form with AJAX, you generate the POST request and not the browser, so you have more control over it. Even if you don't need that control to begin with, in time it might become necessary.
One case would be protection against CSRF attacks on forms. It can be implemented by adding a hidden form input field containing a CSRF token, which is sent together with the form data. But a preferred implementation would be to add a custom header to the submitted POST request. However, you can't do the latter when using the old form submission method - the browser composes the request and you can't add your own headers.
I need to create a very simple application:
I need to have a form that submits data to a servlet
The servlet then queries a database to retrieve a list of reports based on the criteria given by the form
The returned list of documents has to displayed in a div on a .jsp page
I am not sure about the last one (number 3). I know how to call the doPost or some other method using jQuery (but not when triggered by a button), only using a timer, but I am sure it's a similar thing. But I want to keep it as simple as possible and avoid jQuery if possible.
If I call the servlet and return the data without using jQuery, how can I specify the location (i.e. which div) I want it to be returned in.
Where you display the contents of your Ajax request is up to the client-side Javascript.
The servlet will just create the data (either as HTML, or as JSON or XML, depending on what you need on the client).
If you do not want to use jQuery (or prototype.js, or something similar), you have to code the logic for firing off the Ajax request, and for parsing the result (including how to display it) yourself.
I'd say, stick with jQuery. That will keep it "as simple as possible".
If you are not sure how to start a new request when a button is clicked, check out this tutorial.