I encountered a e-commerce website which does the following whenever a filter is applied on the product list page:
For example when you click a "subcategory = 2" (link with href="/productcategory/category1/subcategory2") on the product list page "www.example.com/productcategory/category1"
URI that is displayed in the address bar is changed to mimic the filter request without reloading the entire page. i.e. "www.example.com/productcategory/category1/subcategory2"
An ajax call reloads only a part of the page according to the filter applied i.e. product with subcategory = 2 are displayed.
But also when you enter "www.example.com/productcategory/category1/subcategory2" in the address bar a new page is reloaded as usual.
I am not able to achieve this particular behavior using rewrite rule because whenever I click on a link with href="www.example.com/productcategory/category1/subcategory2" it is redirected according to the rewrite rule and a entire new page is reloaded.
My question:
1. how is it possible to change the URL in address bar but not reload the page?
2. Is it possible to have a rewrite rule which only redirects a page only when you explicitly enter the url in the address bar and hit enter?
To update the url displayed by the browser, without reloading the page, you can use the JavaScript History API - examples here.
I'm not clear what you mean by the second part of your question, rewrite rules get applied when a request is received by the web server - the server doesn't know/care about how the request was triggered, but if you are using the History API to update the url in the browser then no requests get sent to the server, this is purely an in-browser operation.
Related
Description
I'm using React.js with server side rendering using Next.js framework
I have "Search" page, which state is initialized using getInitialProps (loads data from API server), and "Object" page.
User can navigate from Search page to Object page, using simple <a> tag.
On search page user can filter data, each filter do new API request and recieve new data.
The problem
After filtering on Search page, user click on item and goes to Object page. Then user clicks browser Back button.
What is now - I got the same search page which was on first load without filtering. Can anybody explain how it is restored and what exactly is restoring?
What I need - I need restore html and state which was after filtering.
How can I achieve this?
I am working on a Chrome extension, I want to detect when the user has typed a URL. I know about:
chrome.tabs.onUpdated.addListener(eventLisenerObj.onUpdated);
But, it gets called whenever the URL is changed (e.g. when the page is auto reloads, or user clicks on a link, etc.)
I desire to be able to determine that the URL was changed only by the user typing a URL.
You can get this information using the webNavigation.onCommitted(MDN) event. The event listener receives a property transitionType(MDN), which will be different values(MDN) based on the cause of the navigation. Which values you trigger on will depend on exactly what you are desiring. For what you describe, you will probably want 'typed'(MDN), but potentially also 'generated'(MDN), 'keyword'(MDN) and/or 'keyword_generated'(MDN).
The list of possible values is explained on Chrome's History API page (they are listed on the Chrome webNavigation page, but not explained there) (On MDN: TransitionType) (text from the Chrome History API page):
"link"
The user got to this page by clicking a link on another page.
"typed"
The user got this page by typing the URL in the address bar. Also used for other explicit navigation actions. See also generated(MDN), which is used for cases where the user selected a choice that didn't look at all like a URL.
"auto_bookmark"
The user got to this page through a suggestion in the UI — for example, through a menu item.
"auto_subframe"
Subframe navigation. This is any content that is automatically loaded in a non-top-level frame. For example, if a page consists of several frames containing ads, those ad URLs have this transition type. The user may not even realize the content in these pages is a separate frame, and so may not care about the URL (see also manual_subframe(MDN)).
"manual_subframe"
For subframe navigations that are explicitly requested by the user and generate new navigation entries in the back/forward list. An explicitly requested frame is probably more important than an automatically loaded frame because the user probably cares about the fact that the requested frame was loaded.
"generated"
The user got to this page by typing in the address bar and selecting an entry that did not look like a URL. For example, a match might have the URL of a Google search result page, but it might appear to the user as "Search Google for ...". These are not quite the same as typed(MDN) navigations because the user didn't type or see the destination URL. See also keyword(MDN).
"auto_toplevel"
The page was specified in the command line or is the start page.
"form_submit"
The user filled out values in a form and submitted it. Note that in some situations — such as when a form uses script to submit contents — submitting a form does not result in this transition type.
"reload"
The user reloaded the page, either by clicking the reload button or by pressing Enter in the address bar. Session restore and Reopen closed tab use this transition type, too.
"keyword"
The URL was generated from a replaceable keyword other than the default search provider. See also keyword_generated(MDN).
"keyword_generated"
Corresponds to a visit generated for a keyword. See also keyword(MDN).
To differentiate some types of transitions, in addition to the transitionType values, you will also want to look at the TransitionQualifier(MDN). The possible values are (from the Chrome documentation, which are described somewhat differently on MDN):
"client_redirect"
One or more redirects caused by JavaScript or meta refresh tags on the page happened during the navigation.
"server_redirect"
One or more redirects caused by HTTP headers sent from the server happened during the navigation.
"forward_back"
The user used the Forward or Back button to initiate the navigation.
"from_address_bar"
The user initiated the navigation from the address bar (aka Omnibox).
You can have a look at $locationChangeSuccess.
You can get the path like this:
var loc = $location.path();
Then on change of loc you can attach your function.
I am creating a website for a clothing brand but am still getting started with my web dev work. I have an index page with several clothing items on it. When a user hovers over the picture of the item then a hover over effect comes into play and a small "View Item" appears over the item. When the user clicks this "View Item" text it opens a new page with that particular page's info.
The part I am struggling with is how I send the parameter to this item page as I will need some way of knowing what item was clicked. Can I write a jQuery function that will fire when the text is clicked and perform a .post() method to the item.php page passing along the item ID ?
So it would be something like
$.(document).ready( function() {
$("#itemText").click( function() {
$.post("item.php", parameters);
});
})
POST isn't the proper protocol for that. Use GET instead.
GET is vary easy to use with HTML links; it is what happens every time you click a link on a website. Say the page is "products." If the user clicked on product 1, than the URL for that page could potentially be "products/?id=1" (or products/1 if you are using mod_rewrite). The "id" variable with a value of "1" will be available to the PHP via $_GET['id']. With that variable, you can retrieve the proper information based on the id.
POST is for forms where users are submitting fields of data or images. http://html.net/tutorials/php/lesson10.php
If you are attempting to build a pure Javascript solution, then that is an entirely different matter. In that situation you would use Hash tags or HTML5 History API to change the URL. When the URL changes, Javascript is notified, and then whatever actions can occur. However, based on the fact that you specifically said "POST" I am assuming you are using a server-side language like PHP.
If you are opening a new page, you should not POST. If you must POST, you should POST then Redirect, although since you are not actually performing an action I recommend just sticking with a GET request. This way the newly opened page can easily be refreshed and shared by the viewer.
The most elegant way is to use rewrite rules or a router on your server so you can communicate which item to display, for example: http://example.com/item/1/
However you can also just use a GET parameter: http://example.com/item/?id=1
If you need to communicate to Javascript that will be executed on a page you can also use a hash: http://example.com/item/#1
There are several options using GET depending on how you display the item information, and what server-side technology you use.
We are a having search page(jsp) in our Liferay portlet which contains approximately 30 fields. When a person selects some parameter and press submit button then the action method is called and result are shown on the different jsp page. Which is the default behavior.
What we want to implement is that when a person submits the search form then the page must be ajax refreshed on the basis of those parameters.
What our understanding is that we can append the parameters in the URL and make the ajax call.Like in gmail if you do advanced search then the parameters are appended on the URL.
we can appended parameters into url so that when a user pastes url on the browser directly then a action method is called, jsp is loaded and then a java-script will read the parameters from the URL and fetch the proper data.
According to us the problem that we would be facing will be saving of the history in the browser so that whenever the page is changed due to ajax call and user clicks on the browser back button then the previous HTML state should be saved.
Is the above approach correct?
What could be the further issues that we can face while implementing the same?
How can we save the history so as to preserve the previous state?
This can be done by using the BBQ plugin. The BBQ plugin works on the hash tag change of the URL.
http://benalman.com/projects/jquery-bbq-plugin/
I am building a small web site, and on one of the pages there is a d3.js/highchart visualization demo. The visualization is interactive, and can be modified by the user.
When the user leave this page and enter another html page by following a link in this demo page, the content of the page is not saved, and when he comes back, he has to modify the chart again. My question: is there any way to cache this demo page so that as long as the user does not close the browser page, it can be recovered?
My simplest idea is to have each client page a unique ID. So that I will save the status of the page when the user leaves, and when he comes back I can cover its content based on this ID. Then the question is how to implement this ID for client pages.
You can use History API here.
When a user changes the state of the chart, the page URL is updated with all the parameters needed for rendering the chart (via history.pushState call).
On page load you get the initial state (chart parameters) from the url and render the chart correspondingly.
A good thing with that approach is that you even can send such URL to another person, and they will see just the same customized chart.
You could also try storing the page state locally using either sessionStorage or localStorage (DOM Storage guide)
If you have two or more tabs I don't think there is a way to differentiate between then once they are closed. I would use Steve's idea about storing the ID in DB+cookie and when user come back to page I would provide them with a list of all their past modified charts based on cookie and DB query. Then they can choose which chart they want to reopen.
I can think of many ways to do something like this.
If it was me, I would simply store the users chart settings in a cookie, so when they navigate back to the page, you can simply read the cookie for the settings and use them to re-display the chart.
If you want to persists this longer, then send the settings to the server to be stored in a DB. The server can return a unique ID which is then stored in a cookie, or simple use the session cookie to associated the chart settings with a session.
An alternative which doesn't use cookies is to add chart settings to the 'back' url when you navigate away. When the user clicks to go back, the url contains the information necessary to restore the chart states. However, this doesn't work if they click the browser back button.