I am using GWT 2.5.1.
In my GWT web app I have a ComplexPanel object which contains a set of fields(widgets). There are a suggested field (on panel) which gives me the opportunity to find object and info about it. Fields (10-15 of them) contain info about that object.
The problem is when user (client side) has a slow internet connection, fields on form are updated with a delay. And if in moment of delay user click 'Save' button (AsyncCallback), old data (which is not updated) posted to the server.
How it works:
1. Server receive callback from the form and start to processing the data.
2. Server refresh all the fields with new data and end the works.
3. Javascript updating the data on form using about 10 requests.
But: internet is slow and one part of data is refreshed and other no.
4. User click SAVE and mixed data goes to the server.
I need to know (from server side) when all the field are refreshed on client side and server can proceed with a next post request.
Thanks in any advice.
Perform a validation check on click of the save button. There are several things you can do as per your requirement. I have listed one way to validate it.
Set a flag before making the async call as false. For instance, isLoaded = false
Once you have all the fields just update it to true, i.e. isLoaded = true
On save button handler check for isLoaded flag. If false, prompt a message, else save.
Update:
You can count the number of response received. You know that you will get 10 response. So for every response received increment a counter. Activate save only if you have all 10 response recieved.
For a clean way to do this, use gwt-async-future.
Related
I have homepage with multiple listItem each item send a request to a server to get the latest update for the specific item (building tracking packages app) so for example you have 10 packages when you enter the app it will send 10 request to the server to get the updated location for them , what i am looking is when the user click in the item itself if the request didn't finish receiving data from the server it will keep that current request even it's in the detail page of that package . so it won't cancel the request and send another one in the detail page if the first request is still active . i hope i am making sense in this question .
I am using Dio for the request
I am getting your point you want when the first request in progress I don't want to send a new request to at this time. you need to do few things when you are doing a request the first time then set a flag true until you do not get response and use the same flag check on your detail page before API call next time.
This question already has answers here:
Prevent user from seeing previously visited secured page after logout
(7 answers)
Closed 6 years ago.
I have a JSP page with a form where you fill up certain details. On submitting the form i call a servlet which then updates details in a database after that i redirect to a page i display a confirmation message to the user.
The problem i have here is when the user clicks back he goes to the form page again where if he clicks a submit button, it creates a new record in the database.
Consider this similar to a shopping cart example where in this case he would buy the same item twice. But the only problem here is i cannot handle this in backend, i.e. the database can never know a redundant operation is taking place.
I need to handle this from the client side.Bit weird but i have to do it this way.
Basically when the user clicks the back button i don't want him to be able to go to the form page and may be just to some other page.
This is a typical HTML form issue, you can solve it through any one of following methods
1) Server side (page expiration): Since you've mentioned that the page refreshes and goes to the confirmation. You can set no-cache and add a page expiration time as -1 to the page you have that form.
So that when user presses the back button, he will see that the page has expired. He will be forced to load the page freshly. This is the behavior that I see in most banking websites.
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0
Response.CacheControl = "no-cache"
2) Using turn Key method: When the form loads, you can generate a random key in session memory and also embed it as a hidden value in the page.
During form submission, check the submitted hidden key against the value in session. If exists, then add the entry to database otherwise you can reload the page with a fresh key for the user (who might have done that unintentionally).
In load balanced or web farms, consider persisting the turn key in Database against the current user.
3) Client Side (Not recommended) : You can restrict the user from using the browser back button by removing the page from the history. (One side effect is that it will remove the entire history for that browser tab/window)
history.pushState(null, null, document.title);
window.addEventListener('popstate', function () {
history.pushState(null, null, document.title);
});
If you need the same support for older browsers where push and pop states are not supported, you can use following snippet.
<script>
function preventBack() {
window.history.forward();
}
setTimeout("preventBack()", 0);
window.onunload = function() {
null
};
</script>
Before redirecting to the JSP page send these headers with the response from the controller so that the page is not stored in cache and the browser will always request a new page from the server.
response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
response.setDateHeader("Expires", 0);
So every time you go back to that page a new page will be requested from the server and will be displayed with the cleared input fields.
You could implement a PRG-Pattern (https://en.wikipedia.org/wiki/Post/Redirect/Get) using php.
Basically, after successfully submitting the form you redirect to a confirmation page which informs the user that their submission was successful/accepted/etc. and also set a variable which you can later use to check if said submission has been submitted yet.
When the user tries to reload said page or go back you can check the variable and display either the form again or the confirmation page based on if the submission has been submitted already.
I think following flow is the best:
Client submits data to server
Servlet processes it
It returns HTTP 303 redirect to client
Client redirects to success page
After this flow, refresh, back button will work properly.
For more information read Simple Post-Redirect-Get code example
I am working on existing code that uses CGI::FormBuilder, and I've gone through all of the documentation to see how this might work, and I'm not 100% convinced that it will. The code has several free-form fields and 3 buttons: Update, Cancel and Test. The test button sends an email using settings entered into the fields.
In the JS for the form, I use an ajax call when "Test" is clicked so that the perl code in the form executes. The update and cancel buttons return like the form is supposed to when it is submitted. The reason for this is that when the test email is sent, I don't want the user to be taken to a returned page, but remain on the form with the values intact, so that if the values are correct, the user does not have to re-enter them when they want to update the actual values (which updates the values in my DB). Apparently, since the form isn't being "submitted," the values that it attempts to use on this "test" are the values loaded into the form with the page opens - it isn't using the values the user input before hitting the test button. Is there a way to make this happen?
Long question short: with CGI::FormBuilder, can I get the values currently in the fields via PERL without submitting the page? Thanks!
Short answer: yes.
Medium answer: Yes. You can use javascript in the page to send information to your server side application.
Long answer:
You seem to have some confusion about how server and client side code interact with webpages. This is pretty common. Many people expect their to be some kind of communication between the rendered page and the program that generated it. AJAX and related technologies blur the lines here and make things more confusing.
Here's a timeline of a simple, old-school CGI form:
Client requests page. Server receives page request. Server dispatches
to CGI script.
Server executes CGI script.
Server sends result of CGI script to client.
Client renders script results.
User fills out form.
User clicks "Submit". Client requests page with parameter information (details vary with type of request, form configuration).'
Server receives page request.
Server dispatches to CGI script.
Server executes CGI script. Server sends result of CGI script to client.
Client renders script results.
Each message from the Client is handled separately.
AJAX lets you send messages to the server and get the response without clearing the currently loaded page.
So, just throw some javascript code into the html, and set up an onModify handler that will make an AJAX request and pass data back to the server. The AJAX request is just another HTTP request, just like those above, but it runs in the backgound. All you need to do is catch the submitted data and respond. Your javascript needs to catch the response and do something with it.
Answer to the short question is "No".
Answer to the long question is "Yes".
All you need to have two "Submit" buttons: "Submit" and "Test".
The submit by Test will send form to the CGI and CGI will only validate the fields' values and render same form with same values back and message if there is an error in fields.
I have a form that the user submits and returns a result, but it takes a couple of seconds to return the result. I know I can use grails formRemote http://grails.org/doc/latest/ref/Tags/formRemote.html to execute the call asynchronously and update a div on the page, but what I want to do is show another page entirely (with some wait graphics and other information).
Is there an easy way to do this in grails?
You can send data to server asynchroniously (ajax, formRemote), showing 'wait graphics' util you get a response. And redirect to result page right after getting response (and you should have to store state somewhere, and probably have unique url for result page)
I rewrote the title and content 3 times before posting it, I don't find the right way to ask this :P
I have a page that manage a list of notes, I have a CRUD on that page but the items are created and saved in javascript (using knockoutjs).
I create a new note, I add it to the model in javascript and it show up in the page.
The way Im saving the notes to the database is when I add it to the model, I send it via Ajax (async) to the server. So I have my note on screen and in the database really fast.
I send a note without Id to the server and EF will take care of the Id.
So far so good.
Imagine that I add a note but I dont refresh the webpage, so the note is in the database, is in the javascript model too but in the model it doesn't have the id yet.
I make some changes to the note and yeah, I want to update the note in the database... but... how?
I send my note to the server with the changes, but remember, the item still have no Id so I can't say:
Hey EF, give me the note with the ID == xx and we are going to update that note.
The others properties can be changed on the webpage so I have nothing that identifies the note apart from the Id, who doesn't work here.
I tried this:
Send the new note to the server, insert it on the database, retrieve it again (to pick the Id), send it back to javascript and update the object with the Id. So when I edit, I have the Id. Yeah, but the "save" call need to be sync and that destroy the experience.
Any ideas?
EDIT: The sync options is not that slow at the end but there have to be a async way and meh, the thing of "Insert on database", "Retrieve the last item I inserted" and "return back to the client" is a little hackish.
You could return the id of the new record in your asynch call. If you are using jQuery you can subscribe to the "success" callback and as long as your controller returns a JSON with the id of the new record you could update your model on the client side.
Even with this approach, you will need to have a way to identify the item updated on the client side (which is really the root of your question.) For that you can probably generate a random GUID on the client side, send it to the server when saving, and return it to jQuery when returning the ID so that you can identify the correct element to update on the page.