I have an list of paged results that is using AJAX requests to populate next/previous page clicks. I am using the jQuery history plugin to keep track of the page # the user is on. This basically appends http://site.com?query#pg=5 to the url.
If I click through to another page, I am trying to implement a Go Back button in the breadcrumb control. In trying to use:
Request.UrlReferrer
it seems that this does not preserve the # value at all. Is this possible?
The browser is responsible for setting the HTTP_REFERER header and sending that to the server. There has been research done for other questions on Stack Overflow (e.g. this one) and it appears that none of the modern browsers send the hash value.
All is not lost, however. A colleague of mine was faced with a similar situation and ended up setting up an AJAX call to the server to track the hash values on the server as well as the client. It's a bit hack-y, but you can make it work.
Related
This is a very general question. I am using MVC on the back in and JQuery for the front end. I have a select list of values for the user to choose from. I want the user to select the values on at a time by clicking the add button. But this truly does not save them this only stores them in an array. Then when the user clicks the save button i would pass the array to MVC controller method to do the database saves. My problem is that my array is not keeping values. i declare it global but if the page get refreshed or i call a method to filer the list by keyword value the array looses the contents that it had. How to i have an array in JQuery that keeps it value even after a post back?
Normally you shouldn't store unsaved data in javascript array and do postbacks. Obviously if the page is refreshed the data is being lost. So you should choose from two options:
1) You do it on the clientside. So you still have your javascript array, but you don't refresh your page until you are ready to save the data. In this case all the filtering and other stuff you mentioned should be done via AJAX calls from the clientside.
2) You do it on the serverside. So when you have the javascript array and you want to do a serverside postback with complete reload of the page, then you need to push your array to the serverside, but not save it into the database until you are ready. You can temporarily store it Session for example or other collections that persist data between different post backs.
This is high level explanation, I hope you can dig more.
EDIT:
James suggested another valid option of using browser storage of cookies. However storage is not supported in some older versions of different browsers. And I don't feel like this is the task you should use cookies for. It feels like work around to bad architecture.
I am working on an ASP.NET/MVC4 app and I fetch data continuously and my problem is related to caching.
The problem is that when I click on a particular link in my application it works fine, but sometimes it automatically redirects to the INDEX page that is the default page.
I surfed around about this problem and found that it's a problem in Mozilla that it maintains caching of every link. But sometimes some weird things happen and it automatically redirects a particular link to the INDEX page (301 Permanently REMOVED) and also stores it in the cache such that now every time I click on that link it always redirects me to the INDEX page that's been cached.
So now I have to clear the cache in my browser every time I face this problem.
How can I make it not automatically redirect to the cached INDEX page?
You should really expand on what exactly is happening at that particular link you mention because well it should not 301 redirect unless your telling it to.
Also you say I fetch data continuously. What does this mean to us? Why is this important to know? Explain if this changes the link or the data? Are you 404ing the older data or something? That could possibly explain why you 301 back to your index.
Now with the limited information we have been given by you... if you want to prevent firefox from caching your urls/redirects simply make your url have a querystring that updates which each request. Like using a timestamp.
For example: http://example.com/return-data.asp?timestamp=1350668920
Then each time you continuously fetch data update the page's link accordingly
For example: http://example.com/return-data.asp?timestamp=1350669084
I have a page with a lot of dynamically generated check boxes on it. As the users click these check boxes a lot of content on the page changes dynamically via ajax. The end users are complaining that after hitting submit and then hitting the back button to change something, their selections are blown away and they have to do it all over again.
I have seen a few sites (gmail, facebook, etc...) use the hash symbol in the URL to hack the back button so that it performs AJAX calls instead of going back to the previous full page request. I would like to do this to modify the URL before the page submits so that hitting the back button will load their previously selected fields.
For instance:
In Gmail if I am viewing my inbox then my URL looks like this: https://mail.google.com/mail/?shva=1#inbox
Then if I click "Sent Mail" an AJAX call is performed and my URL is modified to look like this: https://mail.google.com/mail/?shva=1#sent
I really like this behavior and want to duplicate it. How is this accomplished?
Do your links actually trigger any javascript or do they just link to the URL with the appropriate hash symbol information?
How do you read in the hash symbol info in javascript?
How does this type of navigation affect search engines? Would a search engine know that two URLS that are the same except for the information after the hash are actually different URLs and index them as such?
What are some other pros and cons of this technique that I should take into consideration?
NOTE: I am using C# with ASP.NET Web Forms and ASP.NET MVC 3.0 in case that matters at all.
To manipulate hashtags, look at location.hash (javascript).
You'll also be interested in the new push/pop state stuff in HTML 5. https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history.
github has done some pretty cool things with this. Check out their blog entry on their tree slider feature at https://github.com/blog/760-the-tree-slider.
There's also the jQuery history plugin at http://tkyk.github.com/jquery-history-plugin/. (EDIT: I see Joe beat me to this one).
take a look at the jquery history plugin http://tkyk.github.com/jquery-history-plugin/ I have used it in the past, and it just might do what you want.
JQuery plugin:
http://tkyk.github.com/jquery-history-plugin/
Another jQuery library that I have used in the past:
jQuery BBQ: Back Button & Query Library
Also, a more scaled down version of the previous if you don't need all it's features and just gives you the hashchange event for all browsers:
jQuery hashchange event
NOTE: Just as a brief intro to the above libraries. The hashchange event is supported natively by newer(HTML5 supported) browsers in which case the scripts will just bind to that event. For older browsers that don't support that event, the script creates a polling loop to simulate the event. In either case you can bind to the event and handle appropriately.
EDIT: To answer your questions:
The links do not trigger javascript, links simply change the url with the hash. The hashchange event monitors this action, and when the hash changes(which is logged in browser history stack) the event fires.
location.hash is used to read the hash value, and any appropriate parsing you would need from that point.
Probably not SEO savvy enough to give you a complete answer on that, but fairly sure search engines DO NOT index hashes.
Pros for this technique is usability as your users will be able to properly use their back buttons. Also any history.back(0) javascript calls will also work properly(i don't like them but people use them). Cons are that as you're initially developing, you can get some quirky bugs depending on how your code is written. All in all though, I think with the use of the plugins much of the legwork has been taken out of the process and it is a great method for usability purposes.
In my ASP.NET WebForms application, I have a WebForm that contains an UpdatePanel and multiple views used for a wizard like interface.
At the end of the wizard, the user has an option of moving to another page by clicking a button. This new web page needs about 5 values from controls in the previous page.
What is the simplest way to do this? (Edit: ONLY using an HTTP POST with data - this is a requirement as I would use database/session otherwise)
I tried using cross-page posting with no luck, possibly because of my update panel and multiple views?
I tried using Server.Transfer, but this also breaks because of the update panel.
Important:
Data has to be sent via HTTP POST - The data can't be stored anywhere
The scenario can't be changed. I can't put everything on the same page
The simplest way to do this is by putting those values in the session object.
You could make a class that describes the data that you need to display on the redirected page. Instatiate a new instance of that at the time the user is filling out the wizard data, populate the new classes' object with the information you need, then add it to the session in the button_Click event before page redirection. On the page you are redirected to, grab the Session object, put it into a variable and extract the data you need.
I recommend you combine all the relevant pages into one; hiding panels that are not in play. ASP.NET will maintain the values of all the controls for you from post to post. The Viewstate was designed for sceneries like you describe. To keep to Viewstate size to a minimum, make sure you fill lookup values for drop-down controls in their "Init" methods.
You don't want to use the session state. The last thing you want is for the users to loose their data from previous pages because they took too long to answer.
If they're moving to another page in the solution, you have a few options.
ViewState - The ViewState is sent with the page delivery. It resides in the HTML, but is encrypted so no one can see the information. Depending on the size of the information, your page size could get rather large.
Session - This puts the information client-side via cookies.
Query String - Using the URI. This should only be used if it's non-sensitive information and if you don't want a user to be able to link back to the same action again.
I have a page with a menu that uses JQuery AJAX calls to populate the page with. To reflect any changes I update the URL with a #... instead of ?... or /... So an URL that originally reads : htpp://localhost/pages/index/id=1 would look like : http://localhost/#pages/index/id=1. If a user bookmarks this, and later comes back to the page, I wonder if it's possible to use the second URL in my route decoding, or if I have to load it blank, then use the same JS/Ajax to populate the page?
In my mind it is problematic to use Ajax in these cases if a user copies the link and mails it to a friend with JavaScript disabled.
edit#1: Fixed some spelling.
edit#2: To clarify the question a bit: I want a site where I can do the following:
(a): with javascript turned on, use ajax calls to replace the content of a div (without reloading the page)
(b): with javascript turned on, bookmark the page as it is after the ajax call i (a)
(c): take the URL, send it to a person with noscript turned on, and have the same page as after the ajax call was made.
(a) and (b) works just fine on my page but (c) is seemingly impossible.
Currently, the only portion of a URL you can update without causing the browser to redirect is the hash. This portion of the URL is not sent to the server in a request and is only available for client-side processing, so it cannot be used to provide a javascript-free way of providing a link.
The issue you are facing is a common one amongst those using AJAX. The best solution I've encountered is to provide a way to view any AJAX-loaded state of every page through a "true" URL, one that will be passed to the server.
This means you have one URL which provides a "snapshot" of a page's state:
http://localhost/pages/index/1/someaction
And an AJAX-specific URL which provides the local state of the page in the client's browser:
http://localhost/pages/index/1#someaction
What you then have to do is provide some means of generating the "snapshot" link to the page from the AJAX version. A "Link to this Page" or "Permanent Link" button is a reasonable option.
This not possible simply because everything that comes after the # sign (fragment identifier) is never sent to the server and there's no way for the server to ever capture this value, so no routing with it.
You could try replacing the '#' with a '?' This will send the rest of it as a get variable, so you may need to do some tweeks, such as change the format to http://localhost/?pages=index&id=1
There are some fancy things you can set up with the web server so that localhost/article/fancystuff is re-directed to localhost/article.php?title=fancystuff
There are a lot of ways of allowing for an AJAX site to work with bookmarks and the back button. But you should ask your self, do you want people to do certain things. Generally, AJAX is used for more advanced web-applications that do not map well to the traditional back and forth model.
EDIT
What with you additions to the question. I will say that seeming as you want to fully support users who are scared of Javascript that you will need to make your site work perfectly with out any AJAX at all. But you should design it in such a way, that the content of pages are included from separate files. This means that when you add in the additional Javascript, it can load the file and place it more or less directly into the content holder on your page.
You do need to remember that you can't force some one to accept a bookmark or force a change to a book mark. What you are after may be best served suing cookies. Luckily, even less people are scared of cookies, hardly anyone disables them, unless they are either paranoid or up to something.