I'm running into the following issue
For the most part, the whole website is generated on the initial load, so there is no changing of pages and new content fades in nicely using Javascript, however there is a portion of my website that is a bit load intensive, and that is the calendar (lots of events read from database to the calendar), so I use a GET/POST request to change months and so on, so now whenever someone refreshes the page it will say the general "Are you sure you want to resubmit blah...ect", the client doesn't want this even though there's no reason for the user to refresh. Is there a way to change headers so when I click a link it will change headers and get rid of that request?
Related
Hi i want to make an effect similar to what this site does http://www.hffm.co.uk/
When you change the page the url up top changes but the content in the sidebar and header stays the same. - i am also curious if this affects SEO.
They stay the same - and do not reload with the page - i figure it has to be some ajax thing? Curious what a system like this is called.
The point is in their case they dont want to interrupt the radio on a link change.
To update the specific part of the page it can be achieved through Ajax and JQuery. Basically both of the those works on the client side which means that website doesn't refresh. You can always make a Ajax request to the server which can return the content in a Json format and that content can be reflected on the page using Jquery.
This is only just a overview of how ajax/Jquery works. But you need to be more specific in what you are trying to achieve and what you have done so far.
i have a grid view and a file upload button on a page. I have users load their data to my site and i parse their files and load onto the gridview. Then using ajax i update the javascript/jquery I allow users to edit their data right on the gridview. My problem is somehting that should be simple to fix but yet im stumped. Once the user is ready to submit the gridview data for good i have an AJAX call to a webservice that i send all the information on the grid. Then i would like to clear the grid and basically start with a clean page again. However i cant seem to clear the grid view. The data just keeps refreshing in the control with the original data. I realize that it has to do with the fact that is bound on the server but i cant unbinded!. i have tried.
window.location.reload()
but all this does its get me a crappy message from firefox telling me that the page is going to refresh.
I saw this on this site from various people
Response.Redirect(Request.RawUrl);
however i don't know how i can trigger that from an Ajax call?. Can i? I'm doing everything through Ajax partly because is where im most comfortable, but i would hate to have to put another button on the page and make the user have to click that button to restart it seems silly. I would like to do a full page refresh on my command. Is there anyway to do this via AJAX? putting a server button does not seem feasible to me due to the fact that once i load data in grid view i use jquery data table and jeditable and work pretty much on the client.
I'm open to suggestion, ideas, tips, anything at this point. So frustrated with what should be a simple task.
Thanks in advance
Miguel
To force a full page refresh without postback you can set the window.location.href value to the current window.location.href
e.g.
Imagine our current scope is the success callback of your grid data ajax submission function, so when the page reloads all new data will be fetched.
//reload the page now that data has been updated.
window.location.href = window.location.href;
If you must use server controls, you can wrap it in an UpdatePanel. This will make it ajax-enabled, but is pretty brute force.
There are nice libraries from companies like Telerik that have ajax-enabled controls. These cost some dough, but if you are doing a lot this it may be worth it.
Another option that does not support server templates/databinding is to use a jQuery based grid like jqQrid.
Thank you in advance to anyone who attempts to help me with this.
I have a form that I am adding checkboxes to via appendChild() - as selections for the user to chose from - based on a bunch of criteria.
When the user checks any of these boxes and then clicks the 'continue' button to post the selection to another page - and then clicks the back button - the checkboxes that were checked by the user - have now been forgotten by the browser (no longer checked).
If I use php to write the checkboxes or simply have static checkboxes - when the user checks any of these boxes and then clicks the 'continue' button to post the selection to another page - and then clicks the back button - the selected checkboxes are remembered (still checked)
My question is:
Why does the browser forget the selections the user made when I create the checkboxes with appendChild()
yet the same browser will remember the selections the user made when using static checkboxes
What is it about appendChild() that is not allowing the same browser to remember the checked selection?
[div id="mydiv"] here is where the checkboxes are going[div]
[script type="text/javascript"]
var newInput = document.createElement("INPUT");
newInput.id = "mycheckboxid";
newInput.name = "mycheckboxname";
newInput.type = "checkbox";
document.getElementById('mydiv').appendChild(newInput);
[/script]
The browser may "forget" dynamic changes to the DOM because different browsers use different strategies for caching web pages. When you hit the back button, the idea is that the browser can display its cached copy rather than re-request the page from the original web server.
It can accomplish this in (at least) two ways:
The browser caches the DOM itself of a page upon leaving it. Upon revisit (forward or back) dynamic changes will persist.
The browser caches only the original HTML of the page at load time (prior to any dynamic changes). This has the effect of losing those dynamic changes--further modification to the DOM with appendChild() or innerHTML is not recorded.
Note that some browsers additionally keep modified form data, and others do not. If your goal is 99+% compatibility across all browsers, then you have some work to do.
To work around this you need to persist the state somehow. You have a few options:
Save data about the modifications to the page to localstorage. Use a key that is generated randomly on first page load and then kept in the page, so that the state changes will only apply to that instance of the page. On page load, if this key already exists, read the change data out and re-apply the changes. Older browsers do not support local storage.
Do the prior thing with cookies. I don't recommend this, as it has the drawback of proliferating cookies. Cookies are sent and received in every request (including ajax ones), so you would be bloating the data being transmitted on every request. Old browsers would work fine with this.
Abandon your dynamic change model and make the changes occur through a post to the server. Then the page will contain the modified html when pulled from the browser's cache. You probably don't want this, but I thought I'd point it out for completeness' sake.
Save data about the modifications to the page via ajax behind the scenes to the server. This is not the same as actually round-tripping each change like the previous item. You still make changes dynamically, but you post an "advisement" file to the server. Then, on each page load, request any adjustment data from the server. This is similar to the first suggestion, but you are using the remote server as your storage. This makes extra net traffic occur on each page load, but the traffic can be minimal as it would be just about this page. It also makes extra net traffic occur that would not normally be sent (the advisement data). A clever system architecture, however, could use this information to persist a user's unsubmitted form data across computers and over time in a way that could be very handy (lets say your user does 199 out of a 200-question survey and then his power goes out--with this scheme he has a chance of painlessly continuing later exactly where he left off!).
Make your Continue button open a new browser window, preserving the original page intact.
Make your Continue button post the data without leaving the page, preserving it intact. You could do a simple lightbox-style overlay.
If the lightbox-style overlay will not work but you really have to display a new page and don't want it to be in a new window, then redesign your site to work similarly to gmail: where pages change only through javascript, and only through using #hash tags at the end of URLs to control behavior. This can be difficult but there are libraries out there that can accomplish it. (For some browsers one has to resort to polling to see if the hashtag has changed.) The basic idea is that when you click a link that points to the same page but has a tag on it such as About the browser will initiate a page load event, and will push a new context into the history forward/back stack, but will not actually load a new page. You then parse the updated URL for the hash code (which maps to some kind of command) and carry it out. Through careful choice of the proper hash codes for each link, you can hide and display the appropriate page dynamically through Javascript and it will appear as if the person is navigating around a real web site. The reason you do all this is that, because the page never loads, you not only can maintain state in Javascript, you can maintain your DOM state as well--you simply hide the page that was modified by the user, and when the back event occurs that means to visit that page again, you display it, and it is exactly how the user left it. Advantage: If your site requires Javascript to operate, then you are not taking a risk by using even more Javascript to accomplish it. Disadvantage: Completely changing the architecture of your site is a LOT of work and can be difficult to get working on older browsers. To get started with this see Unique URLs. You might try out the jQuery hashchange plugin. If your web site has wide distribution you will want to be sure to address search engine optimization and web usability issues. You may want to see this SO page on detecting back button hash changes.
Use the same strategy as in the prior point but instead of doing it with hashtags, use the new HTML5 history.pushState() and history.replaceState() methods--see Mozilla browser history.
If your goal is not 99% compatibility across 99% of the browsers in use, then please let us know what you are aiming at, as there may be a shortcut possible.
Update: added an option #8
Scripting pages doesn't stop at state management. It includes state management.
This means scripted state changes such as scripted page transitions(pages that internally navigate), content panes, popover menus , style changes and of course, form input and selections are all the responsibility of the scripter.
So, in answer to why .. it is because you did not manage the page state you scripted.
If you want your page to work as you seem to expect you can manage the page state changes you script yourself, use a js lib that manages page, or perhaps in your case form, state, or use the http(s) client/server state management and load up the session state, or in your case just the form state, at the server.
I am trying to figure out the best way to acompish "unobtrusive" forms for a user (within a web app).
The purpose: keep user on the site by not asking to fill unnecessary form in. Ask for the details as only when such are needed.
The requrements are:
User should provide additional details only when it is required (email to receive notifications, login required for account page, save credit card details when checking out).
User should not leave the current page providing the additional details.
The implementation would be fairly easy if all requests would be AJAX ones. It would be easy to analyse the response (401 or so) and show the appropriate lightbox-form.
I do not see how it can be done "the right way" with plain anchors and form submits as in both cases the user actually leaves the page (by following the link or submitting a form) and there is no way to analyse the response on the client side.
Converting all links and forms to AJAX ones would be just silly.
The closest analog to what I want to achieve is the default Basic Authentication dialog in most of the browser. But obviously that just doesn't fit my requirements.
Any creative suggestions how to do that for non-AJAX requests?
Regards,
Dmytrii.
In a page sense, where "page" refers to what the user sees and not what the URL is, I only can think of following ways to update independent parts in a page with JavaScript (and thus Ajax) switched off:
Frames
Iframes
Using held-open connections there are two more ways to update a page, however these do not work reliably in all cases:
Animated GIF
CSS DIV tags with absolute positioning.
Note that this needs that your Server can keep open a session for each person looking at the page, which can be thousands. If this does not work the only possible workaround is with FRAMEs and automatic refresh, which is somewhat clumsy.
As I think that you do not want to use Frames and you do not want to render animated GIFs, I explain the CSS DIV way:
When you load the page you do not finish loading it. Instead the connection is kept open by the web server and the script handling the connection waits for additional information to arrive. When there is additional data, this is sent to the browser by encapsulating it into additional DIV tags which can overwrite other parts of the page.
Using "style" in the DIV tag and CSS position:absolute these can overwrite other information on the page like a new layer. However you need either position:absolute or must add this data to the end of the page.
How does this work with forms?
Forms usually have a known size so you can put them into IFRAMEs. These IFRAMEs get submitted to the webserver. The script there notifies the other script that new data must be output, so the waiting script renders the response and displays it in the page while the script which took the submit redisplays the form with fresh values only.
How does this work with 404 and anchors?
I don't really know because this must be tested, but here is a hint how I would try to implement this:
We have 2 issues here.
First the URL must not point to other pages but back to a server script again, so the href is under control. This script then notifies the waiting script to update the page accordingly, for example by retrieving the page and sending it to your browser. The script can check for 404 as well.
Second you must hinder the browser to switch the page when clicking on the anchor. This probably involves some clever tricks using CSS, target and server side status codes (like "gone" or redirect to the current page, whatever) to keep the browser from switching the page. I am not completely sure if that works, but if you remember download pages, these show URLs which do not switch the page but have an effect (downloading the file). That's where to start to try to hack browsers not leaving the current page without using JavaScript.
One idea not followed here is not keeping the connection of the page open but the CSS file and send new css information to the browser which then "fills in empty stubs" using the CSS way. But I doubt that this works very well, most browsers probably will parse the CSS only after loading finished, but perhaps I am wrong.
Also note that keeping a connection open never finishes the page loading, so you will see the busy-logo spinning all the time, which is unavoidable with this technique.
Having said this all I doubt you get around JavaScript.
What I wrote here is very difficult to do and therefor usually is not used because it scales badly. And it is a lot more difficult than using JavaScript alone (that's why I explained it).
With proper AJAX it is much more easy to reach your goal. Also note that you do not need to change your page source much, all you need is to add a script which augments the page content such, that for example forms suddenly use AJAX instead of a direct POST with re-rendering the page. Things which cannot be detected easily then need some hints in the tags such that the tag scanner knows how to handle the tag. The good thing then is, that with JavaScript switched off your page still works - however it then "leaves the page".
Normal HTML just was not designed to create application-like web pages like we want to see today. This all was added using JavaScript.
About popup forms
The Basic-Auth-Handler reloads the page after the user enters something into this dialog, only if cancel is hit the current page is displayed.
But there are two ways to present additional query-popups in a page using JavaScript:
The first one is the javascript "prompt", like in following example:
http://de.selfhtml.org/javascript/objekte/anzeige/window_prompt_vor.htm
(Click on the "Hier").
The second one is "JavaScript forms" which are like popups within an HTML-page.
However I consider popups to be far too intrusive and bad design.
Ajax and JavaScript is the easiest way
Unfortunately using JavaScript is never easy, but if you think JavaScript is improper or too difficult, there is no other technique which is easier, that's why JavaScript is used everywhere.
For example your page onload-Script can cycle through all Anchor-Tags and modify them such, that clicking on them invokes a function. This function then must do something clever.
Same is true for Forms. Fields which can be modified (like the user's eMail address) then have two views, on is visible, the other one hidden. The hidden one is a form. Clicking on the eMail address then switches the view (disables the first div and enables the second), such that suddenly instead of the eMail address a text form field is there containing the eMail address. If you click on the "OK" button the button changes the look into a spinner until the data is submitted, then the view switches back to the normal one.
That's the usual way to do it using JavaScript and Ajax. And this involves a lot of programming until it works well.
Sorry for not shortening this post and missing code snippets, I am currently lacking time ;)
Hidden iframe.
Set target attribute of the form to the name of the iframe. use the onload event of the iframe to determine what is the response.
Or, if you really dont like any javascript, don't hide the iframe and instead present it in a creative manner.
CSS to hide an element
#myiframe { position:absolute; left: -999em; display: none; visibility: hidden; }
But normally, display: none is enough. This is just an overkill.
I am soo angry right now. I lost hours and i dont know why this happens. Its a semi rant but i'll try to keep it short
My code would not work, even after refreshing it was broken
I fixed my code or so i thought because it stops working without me changing anything (you would think i am imagining this...)
I somehow decide to make a new window or tab i run my code and verifies it works.
I write more code and see everything is broken again
I write test in a new window and see my code does work
I see my code doesnt work and firebug DOES NOT HELP
I notice when i create a new tab everything works
I realize refreshing does not work and i MUST make a new tab for my code to work.
Then i knew instantly what the problem was. I modify a display:none textbox but i set the values incorrectly. I cant see it because it is hidden. Now some of you might say its my fault because when doing a refresh all of the data may be cache. But here is the kicker. I was using POST data. I posted in between of the refresh each and everytime.
Whats the point of using POST when the same data is cached and use anyways? If theres no chance for a search engine to follow a block user get link then why should i bother making anything post when security or repeat actions are not an issue? POST didnt seem to do anything.
Sounds like you're being hit by form-field-value-remembering.
When you use back and forward (but when the bfcache isn't used in browsers that have it), or in some browsers when you hit reload, the browser attempts to keep the values of each form field that were present when the page was last unloaded. This is a feature intended to allow the user to navigate and refresh forms without losing all the data they're laboriously typed into them.
So you can't rely on the value of a form field being the same at page load time as it appears it should be from the HTML source. If you have DOM state that depends on the value of a form field (such as for example a form where some of the fields are hidden or disabled depending on the value of another field), you must update that state at page load time to reflect the field values that the browser has silently dropped into place (no onchange events occur). And don't use hidden inputs to store scripting variables at all.
The exact behaviour varies across browsers. For example some browsers keep the values of hidden fields and some don't. Mozilla and WebKit put the new values in instantly as the fields are parsed into the DOM, whilst IE only does it on window.onload... and Opera, aggravatingly, does it just after window.onload, so you can only catch it by setting a 0-timeout to update state after onload. It's a nasty mess.