I have RESTful app which reacts on GET request and I need to store the state.
For example
localhost/subs?search=John
Then I need to add other parameter division by clicking button.
localhost/subs?search=John&division=develop
Meanwhile the data output will be distributed on pages. And appear new 2 parameters size and page.
localhost/subs?search=John&division=develop&size=5&page=0
In this situation when I click on next page button my url is resetting.
I’m really confused. How to save state and if parameter is already has in url then it should be changed for new value, if parameter doesn’t exist then append it.
If there good options?
At least I can use JavaScript by taking it and parsing url.
But I think it’s not good at all.
As I know, the RestAPI doesn't save any request parameters (Maybe you can do by adding them into a session attribute, but it's just made the logic code become more complex).
At least I can use JavaScript by taking it and parsing URL
Yes, I think you should.
Happy coding!
I have a Spring MVC application where I sometimes have to add a new object to a list, and at some point, save the page. At every point where I need to add something to a list, a controller action is called and when it is done adding it returns the page. The state of the page then is lost. (ie. scrollbar position). I would like to preserve the page state, also after saving the page (which does a redirect to the new page)
Right now I am putting some variables in the session, and reading them out EVERY time. I find this quite ugly.
Does anyone know like a solution to this? Or any third party dependency which can make my life easier on this? :)
Thanks in advance.
Ps. I hope my question is clear, and not too abstract. If so, I will try to clarify it more.
One way to avoid the complete page refresh is to use ajax. Submit the new List item via an ajax request and the browser will not perform the full refresh.
Exists another variant. You may perform AJAX call to Controller method and send only the data you need to save. After that through #ResponseBody annotation you can return refreshed data or any other result. So this solution force you to use AJAX call. You may use JQuery for this purpose.
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 try to find pattern how to return 'prompt()' result in java like http://www.mysticcoders.com/blog/wicket-ajax-confirmation-modal-window/ (but in this case author using 'confirm' instead of 'prompt' and doesn't return anything from javascript). Now I am using hidden field in form and update this field before submit, but maybe you know how to solve this problem more elegant (for example using AJAX components in wicket). Thank you for your time.
If you just want so submit the prompted value within your form, your hidden field approach looks adequate to me. If you want to call some Wicket code on the server with the prompted value independently of the form submission, see How do I call Java code from JavaScript code in Wicket?
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.