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.
Related
I have a list of products on page A and want to add them to a shopping cart on an external page B (by clicking a button on page A). I already have the correct Ids from page B and their single product page url. I'm looking for the correct (and secure) approach on this one.
My current approach would be using a browser extension which passively listens to the specific button click on page A and then takes action (e.g. by automatically opening a new tab and submit every product page individually). Extending this idea a bit further I could check the form submit url of page B and make use of it automatically.
However using an extension limits this feature to desktop only.
I already thought about using a bookmarklet but using that approach a user always has to actively activate the bookmarklet (from what I know) instead of it listening passively ...
Am I on the right track here or is there another different way I could go?
You can try to add your item id to a variable array each time you select one and then pass the array variable to the page B either by using arguments or using a POST method.
I have a little web app (which only has 1 page) that allows user to input and select some options. The input texts and selections will be displayed in another div in the form of table. You may want to refer to the example here: http://jsfiddle.net/xaKXM/5/
In this fiddle, you can type anything and after you clicked submit it will get the text input and append them to another table #configtableTable
$('#labels #labelTable tr:last').after(addmore);
$('#configtable #configtableTable tr:last').after(displaymore);
I'm using cherrypy as a mini web server (and thus major codes are written in python) and i know that it has session here but i have no idea how to use it at all as the example given is not really what i want to see.
FYI, i'm not using PHP at all and everything is in a single page. i simply show and hide them. But I want the page to remain as showing #configtableTable and hiding #labelTable even after refresh. Note that the fiddle is just part of the web app which will only show all these after getting a reply from another device.
Not sure about cookie because all the links i've found seem broken. How about jQuery session? Is it applicable in my case? I need some examples of application though :(
okay, to conclude my questions:
1. can i save the page state after refresh? and how? which of the methods mention above is worth trying? is there any examples for me to refer? or any other suggestions?
2. can i simply DISABLE refresh or back after reaching a page?
Thanks everyone in advance :)
Don't disable Refresh and / or back navigation. It's a terrible idea - user's have a certain expectation of what actions those buttons will perform and modifying that leads to a bad user experience.
As for saving state, while you could use session or cookies, if you don't need that data server side, you can save the state on client side as well.
For example, you could use localStorage
Alternatively, you could create an object out of the data in the table, JSON.stringify() it and append it to the url like this: example.com#stateData.
In case of either option, at page load, you'd have to check if there is state data. if you find there is, then use it to recreate the table, instead of displaying the form.
The disadvantage of the first, is that not all browsers support localStorage.
The disadvantage of the second is that URLs have a length limit and so this solution won't necessarily work for you if you're expecting large amounts of data.
EDIT
It appears that Midori does support most HTML5 features including localStorage however, it's turned off by default.. (I'm trying to find a better reference). If you can, just point Midori to html5test to see what HTML5 features it supports.
I'm a student stuyding the bioinformatics.
I'm trying to make a crawler where I can put the lists of queries and get the results automatically.
The site I'm interested in is the GEO DataSet site.
www.ncbi.nlm.nih.gov/gds/
If I wish to send a query like 'lung cancer', I can use the following address.
http://www.ncbi.nlm.nih.gov/gds/?term=lung+cancer.
And there are 549 pages showing up.
I can get the results of the first page, but I don't know how to move to the next page.
I mean, how can I move to the next page by changing the URL?
The Next button is linked as "www.ncbi.nlm.nih.gov/gds/?term=lung+cancer#" and I don't think it's the actual URL that button is linked to.
I'm new to the JavaScript, but I heard the hash sign (#) is processed in the JavaScript
I wonder if there is something I can do like
"http://www.ncbi.nlm.nih.gov/gds/?term=lung+cancer&page=2"
so that I can move to the second page.
If you use any debugger tool (Firebug for Firefox, WebDeveloper for Chrome) you should be able to monitor the network traffic. If you do that, you'll see, that by clicking the next button a form is submitted, sending data via post method. However, when concatenating the post data to a get string you can also get to the next page. The following url lets you access to second page of the result set (warning: really, really long!):
http://www.ncbi.nlm.nih.gov/gds/?term=lung+cancer?term=lung+cancer&EntrezSystem2.PEntrez.Gds.Entrez_PageController.PreviousPageName=results&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.sPresentation=docsum&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.sPageSize=20&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.sSort=none&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.FFormat=docsum&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.FSort=&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.FileFormat=docsum&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.LastPresentation=docsum&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.Presentation=docsum&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.PageSize=20&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.LastPageSize=20&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.Sort=&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.LastSort=&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.FileSort=&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.Format=&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.LastFormat=&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Entrez_Pager.cPage=1&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Entrez_Pager.CurrPage=2&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_ResultsController.ResultCount=10973&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_ResultsController.RunLastQuery=&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Entrez_Pager.cPage=1&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.sPresentation2=docsum&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.sPageSize2=20&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.sSort2=none&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.FFormat2=docsum&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_DisplayBar.FSort2=&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Entrez_Filters.CurrFilter=all&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Entrez_Filters.LastFilter=all&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_MultiItemSupl.Taxport.TxView=list&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_MultiItemSupl.Taxport.TxListSize=5&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_MultiItemSupl.RelatedDataLinks.rdDatabase=rddbto&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Gds_MultiItemSupl.RelatedDataLinks.DbName=gds&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Discovery_SearchDetails.SearchDetailsTerm=%22lung+neoplasms%22%5BMeSH+Terms%5D+OR+lung+cancer%5BAll+Fields%5D&EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.HistoryDisplay.Cmd=PageChanged&EntrezSystem2.PEntrez.DbConnector.Db=gds&EntrezSystem2.PEntrez.DbConnector.LastDb=gds&EntrezSystem2.PEntrez.DbConnector.Term=lung+cancer&EntrezSystem2.PEntrez.DbConnector.LastTabCmd=&EntrezSystem2.PEntrez.DbConnector.LastQueryKey=1&EntrezSystem2.PEntrez.DbConnector.IdsFromResult=&EntrezSystem2.PEntrez.DbConnector.LastIdsFromResult=&EntrezSystem2.PEntrez.DbConnector.LinkName=&EntrezSystem2.PEntrez.DbConnector.LinkReadableName=&EntrezSystem2.PEntrez.DbConnector.LinkSrcDb=&EntrezSystem2.PEntrez.DbConnector.Cmd=PageChanged&EntrezSystem2.PEntrez.DbConnector.TabCmd=&EntrezSystem2.PEntrez.DbConnector.QueryKey=&p%24a=EntrezSystem2.PEntrez.Gds.Gds_ResultsPanel.Entrez_Pager.Page&p%24l=EntrezSystem2&p%24st=gds
This complete GET string contains all search parameters like items per page, search terms, display and way more. You should be able to figure out which parameter is used for the offset (cPage and CurrPage are your friends) and then alter it to your needs.
EDIT: Btw, to find javascript events bound to an HTML element, you can use the bookmarklet found at http://www.sprymedia.co.uk/article/Visual+Event+2
I have a bit of an interesting situation.
I have an application that uses an MVC framework to deliver the view to the user.
This is great for the overall design perspective.
There is a wrinkle though.
At certain times a user could be doing something on a page and they would be required to go to another page to perform a look-up service. I need to be able to uniquely identify each page that they go to and I am not able to use the URL, because all the subsequent pages that I visit from the parent page have the same URL.
Just an fyi, I care about this because I'm attempting to store the last known scrolling position on each page in cookies.
Example -
They are working on Page A.
They click a link from A and they are taken to page B.
On Page B they enter some values and click Search which will query a DB
A list of results is returned.
They can then select to "Return Value" of one of those search results.
The value is then returned to Page A.
When I run the following on each page (A and B) -
alert("${channelUrl}");
They are an exact match!
What else can I do to determine what page I am on within my javascript without resorting doing any sort of server side AJAX calls etc...?
Is what I am asking even possible?
Currently I am attempting to solve this problem by counting up the number of text fields on the page and appending that to my cookie name. This is not ideal, especially if a user visits a page that happens to have the same number of text fields.
Thanks.
One common way to handle this sort of thing is to open the second page in a new window. With this approach the parent and child windows know which is which (the child refers to parent as window.opener, and the parent refers to the child via the return value of the open call) so there's no need to manage URLs or anything to keep track.
People often use the part of the url after # to keep track of where you are under the a single URL. This is built-in supported with My Section which takes you to the element with id "my-section", but you can use libraries that take control of this section of the URL in other ways.
I am creating a site that utilizes the jQuery UI tabs. Whenever the user flips between the tabs, the tab they just left is posted back to the server in order to save the state.
One of the tabs in particular is a bit complicated in that, if I select a particular data option, other options need to be disabled. However, because of the POST, those options reenable themselves in the view when I go back to the tab. The current solution I have found to fix this problem is to check to see if the specific option was selected and to disable the other options appropriately (which happens as the user flips back to the tab). However, this seems like too much work. I am wondering if there is any way for the disabled attribute to remain on the various options even through the POST. (If the answer is "No," I'll accept that, but I wanted to see if there was another alternative to ensuring the view is correct for the user.)
Edit: I wanted to add some code demonstrating the post that I am doing when the user switches tabs. (Particularly based on the responses.)
$.post($(form).attr("action"), $(form).serialize(), function (data, success) {
if (success) {
// Inject the resulting form back into the parent of the page.
var parent = $(form).parent();
parent.removeData($(form));
parent.html(data);
processTabAfterLoad(tab_index);
}
});
The processTabAfterLoad function does all of the selections and setting the state of the tab back to what it previously was.
If I were you, I'd take a different approach. It seems like your goal in posting back to the server when navigating is to preserve a user's location in an application so when they return, you can restore this state. Rather than reloading the whole page through a POST, what you could do instead is do an "AJAX" post to tell the server to store the user's UI location but do all of your UI enabling logic client-side. That way, not only will UI transitions look smoother, but you'll reduce server load and make the application more responsive.
It'd only be when the user does the initial GET of the page that you'd need to look up the last-known UI location. If there's something stored for that user, you would add logic to set the UI's initial state when the page loads.
Update:
Indeed you are doing an AJAX post, but you're also apparently inserting the HTML response from that post into your UI. That is a somewhat unusual pattern (excepting ASP.NET update panels). Typically, you'd either POST the data and expect no content in the response or you'd receive data back from the post which you'd apply to the UI rather than receiving a fragment of the UI.
If you're committed to the way you're currently handling form submittal, you could look into the jQuery live function which can apply changes to elements as well as newly-inserted elements that match the criteria.
Tabs are usually navigation techniques. Imho, its a bad practice to postback and redirect when a GET (i.e. an ordinary link) would do. A GET resets viewstate back to a known point, is a small payload, doesn't require a page life cycle that gets discarded anyhow before the redirect, etc.
I could also be completely wrong here-- I'm making some guesses since I can't see any code.