I have a page that is generated from a bunch of grails templates being rendered, with javascript widgets and stuff, that specify parameters for a search engine we are developing. The problem is, if someone clicks on a person returned in the search results and it takes them to another page, and then they hit the browser back button, the search parameters and dynamically created widgets and previous search results are all gone.
I dont really want to have to programmatically re-build the page based on the search parameters (which I can save as a session variable), and I would then have to re-run the search query again to get the results back. is there a way to save a page just as it was created?
Thanks
Popup a javascript window with information about that person instead of taking them to another page. In the worst case set the target of the person link to _new and that will force open a new browser window/tab.
At some place the search parameters have to be saved. Either on server or client side. On the server side you only have the options session or flash scope.
On the client side you could store those values in a cookie. This needs some bits of javascript.
However theoretically the browser will keep manually changed form field-values out of the box. He is identifying the form fields by its name/id. It should not be necessary to do any programmatically things, except if you are loading some parts of the page via AJAX. Maybe you can doublecheck, that the input fields have static name/id pairs or you have some meta/cache/html settings, which prohibit such mechanism (double check, that your form does not have autocomplete="off" setting set. This will prevent the browser to refill your form fields.
Grails itself does not offer things like you need out-of-the-box (and I do not know if other frameworks have - maybe except for Seam, which has a concept of conversation scope; but even this feature will not work out-of-the-box if the user uses the browser back button). The easiest way is to make your search page some kind of cacheable (for the browser, by settings HTTP-headers or meta tags), so that the browser is not trying to reload the page from the server again, if the user presses the browser back button. And double check the autocomplete="off" setting.
Related
I have a react app. I need to send a user to fill a form(s) on an external page (in another domain), and then get back with the result (success/fail) of the form submitted there, to continue the process in my react app.
I don't control the other domain or the app there (it is a 3rd party), but I can ask them to make changes (and maybe they will agree, if it is not too complex).
The external forms are not html only, trey have javascript in them as well (for example to autocomplete cities names, etc).
How can that be achieved?
I thought about few options:
Iframe + postMessage
Popup + postMessage
Redirecting, and asking them to change site so they will redirect back to me on form completed.
Asking them to make a special form just for me that I can embed inside my design.
Issue with 1,2,3 is that it will show the entire external page, which has not just the form, but also other links, so user can get "lost" and never come back.
Is there a simpler way to do that? The less I need to rely on them to make changes the better, and if I can avoid iframe/popup/redirecting and show the form inside my app is better
I've got an html from on a public access tablet.
Is there a way to reliably prevent a user from going back in history to view past form submissions?
I'm looking to solve it either server-side or using javascript, or combination of the two.
I tried javascript code that prevent the back action, but it only works on the immediate back, press and hold to view further back options still allows going back.
The form is set to remember values when submission fails, but should not be able to get them after a successful submit.
is this perhaps better to do using sessions and handle using php?
There are many ways to prevent re-submission of forms through clicking the back button:
One way is to set all the form fields to be empty, this can be done on load of the page.
You could use sessions to ensure that the user has already submitted the form.
Cookies and/or local storage can be used as well.
However, querying the database to check for duplicates or resubmissions, or setting the form fields to empty strings on the client side would be a better option, as a user could delete cookies and clear local storage.
A site I am working on requires user information to be collected from a form when the user presses the submit button. The site will then take the information and plug it into a more robust form on a different page, so the user does not have to retype the information twice.
Is this possible using javascript?
Any help appreciated.
Once the user leaves the current page, the JavaScript on the original page is no longer running, They will load up the other page and run that page's JavaScript.
Do you have ownership of both pages?
If so, then you can leverage the form GET to pass information across pages, so the next page will have a Query string, and JavaScript can parse that.
Another way to move data from one page to another is to use Cookies. So it really depends on how much data you want to move around.
But I highly recommend that you leverage the server-side technology to handle the form GET or POST and carry information across pages.
This completely depends on the OTHER site. You can have a form with the same field names and post it to the same URL the other site's form uses.
BUT - if that site checks to see where the original post came from, it may block you out.
I want to develop a small javascript tool for browsers.
This tool can extract some content from current webpage and submit it to another site.
The whole work flow is divided into 3 stages.
The first stage is to extract content from current page.
The second stage is to log in. The user needs to enter their username and password in a login form.
The third stage is to submit the content abstracted from the first stage.
My problem is that the third stage needs the cookie from the second stage.
I have tried iframe, but failed.
Cookies need to be, at least, on the same top domain and the cookie set to be visible up to the top domain. If you are on another domain, this is not a viable option.
Another way you can pass data is via a form submit. Assuming you are on a page on a foreign domain, using this technique, you can have your script build a login form that submits to your site, along with the data you gathered. It also means the 2nd and 3rd step is merged. No cookies needed.
Our intranet site has an unusual set of requirements.
It functions like a multi-page desktop application. For a single client, our users will be entering information on up to 30 screens.
It is an Asp.Net MVC3 based site with all session state disabled for efficient operation on a web farm.
For privacy reasons, we cannot use the query string to show any client information. We are currently using cookies to store client identification.
Our user base wants to have multiple tabs open in one browser (IE, FF or Chrome).
If I assume that the user is only going to be using a single, then I can store the client info in a simple cookie and everything works fine.
When the user opens a second tab, it would reuse the same cookie. Not the desired condition. So is it possible to determine the difference between the browser tabs?
You can use the sessionStorage object to store data specific to a single window/tab. It works just like any other JavaScript object, in that you can assign (sessionStorage.foo = "bar"), retrieve (baz = sessionStorage.foo) and delete (delete sessionStorage.foo), but unlike other JS objects any properties set will be persistent across pageloads in a single window.
The only downside is that it doesn't send this data to the server. You have to do this yourself using an AJAX call.
Look into the window.name variable. On page load you can put something unique in it, like the date/time, and store the same thing in your cookie (if its not present). If the user opens a new tab (or window), the value will be empty and the cookie won't be. window.name persists across page loads (if memory serves), so this will allow you to uniquely identify each tab.