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'm very new to jsp and is unfortunately working with Websphere 5. I'm now trying to make a simple web page that can show information from the enterprise beans and got instructed to send information from the jsp-page to the servlet via a hidden field in the form. This seems like a sort of out dated way to do things. Are there better ways?
As I said, I'm new to the jsp-part, but do know Java and html, but no JavaScript.
Grateful for help!
so you want
store some data used by jsp and servlet
want it to be hidden to user
No html hidden form element.
No javascript
how about maintain the data in session object?
Hi All
I have a requirement like, from some web page on some event user will redirect to MyApp's login page with some parameter. I want to test MyApp is able to get that parameter or not. To test that i made another app in which i am using (code is below ). But this is showing parameter in url which i don't want. I also want to know what other ways are there to redirect/forward to some another url with parameter ( parameter should be hidden hiddn ).
<%
response.setStatus(HttpServletResponse.SC_MOVED_PERMANENTLY);
response.setHeader("Location","http://localhost:8080/MyApp/login/login.jsf?user_id=inc&reference_id=123456789");
%> THANKS
It's not possible to do POST redirects, so you can't just redirect with a POST from your scriptlet.
What you can do is:
Build an HTML form in POST with the parameters that you want to pass, but remember, the POST perceived security is brittle, since with a tool like firebug anyone can see those variables (or they can just look at the html source).
A way around the problem is use encryption or one time passwords (that last for a session). I used this way, to connect seamlessly a Java application with PHP. If you're interested I could look it up and share the details of that solution.
First of all, do not use scriptlets. If you dont want to see the parameter in the URL, don't send it with the URL. You can do a POST submit or pass it as a hidden variable from your page.
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.
I am trying to clear everything on my HTML form when I visit it from a hyperlink entry.
Any ideas? My development language is java.
are you using session-scoped data? if so, close your browser and open it again.
I'm not sure the application is, but one way to accomplish this would be to use JavaScript. For example, if it is acceptable to clear the form every time that page is visited you could write a quick function that clears the form when the page is loaded (i.e., using the onload event).
If you only want to clear the form when the page is hit from that link you could add a param to the URL (e.g., clearForm=true) and use JavaScript to pick up the query string and clear the form when that parameter is present.
This is, of course, a purely client-side solution. For a server-side solution it would be helpful to know what framework you are using.