I have a .php file from another server which processes data. This data is tabulated. So whenever I call this page using $.post with the right parameters, its response is nothing. I checked my code and maybe the header is the one responsible for it. What I want actually is to return my tabulated data so that I can populate it to another page. My header is like this, header("Content-type: application/json");. What am I missing?
$.post('http://333.333.33.33/reporting/table.php?loc_id='+locid+'&loc_type='+loctype+'',{loc_id:locid, loc_type: loctype},function(data){
$('table#default_table').hide();
$('div#generated_table').html(data);
});
that is how I call my $.post.
You my friend have become yet another victim of the Same Origin Policy - luckily, this can be "worked around" by using a method called JSONP. This does, however, require a GET rather than a POST request. I myself had to use this, and I had no idea about how it worked, so I asked a question and got a wonderful answer!
You need to communicate between 2 different domains right?
You need to use JSONP here instead JSON.
Check Detail
Related
Alright, so I've looked at a ton of questions, but I only found 1 that resembled what I am trying to do. Here is the link to it: Passing POST data from one web page to another with PHP
I want to pass data from one PHP file(we'll call it editData.php) to another PHP file(we'll call it submitData.php). Neither file has any HTML elements (pure PHP code I mean). The first file(editData.php) receives $_POST data, edits it, and needs to send it to the second file. The second file(submitData.php) needs to be able to read in the data using $_POST. No sessions nor cookies can be used I'm afraid.
In the linked question above, the answer accepted was to create hidden fields inside a form and POST the data from there. This worked for the OP because he had user interaction on his "editData.php", so when the user wanted to go to "submitData.php", he would POST the data then.
I can't use this solution(at least, I don't think I can), because I am accessing (and sending $_POST data to) editData.php from a javascript AJAX call and there will be no user interaction on this page. I need the modified data to be POSTed by code, or some other way that does the transfer 'automatically'(or 'behinid-the-scenes' or whatever you want to call it). submitData.php will be called right after editData.php.
I don't know if I can rewrite submitData.php to accept GET data, so count that out as well (it's a matter of being able to access the file). I really don't want to echo stuff back to my original JavaScript function(and then AJAX again). I am encrypting info in editData.php, and (while it sounds silly to say it) I don't want to make it easy for someone to develop a cipher for my encryption. Returning values after being encrypted(viewable with Inspect Element) would make it too easy to decipher if you ask me.
I feel like this issue could come up a lot, so I'd expect that there is something obvious I'm missing. If so, please tell me.
tl;dr? How can I send data to a PHP file via the POST method while only using code in another PHP file?
Well you might consider just streamlining your approach and including the submitData logic at the end of the editData file. But assuming that this is not possible for some reason (files live on different systems, or whatver), your best bet might be to use cURL functionality to post the data to the second script.
If the files are on the same server though I would highly recommend not posting the data to the second script as this will basically just double the amount of requests your web server needs to handle related to this script.
I am thinking of developing a website in PHP and I was thinking of using AJAX in order to send data to, and retrieve data from a server asynchronously (in the background) without interfering with the display and behavior of the existing page.
So my question: would it be better to use AJAX to GET or POST to php pages or any other options are possible?
There are not that many options when it comes to submiting data, either you use AJAX or use the normal http message like GET or POST. If you would like to determin witch is better i would say: it depends.
Ajax seems to me like a great way of making more dynamic a part of your site, but i dont think its always practical to use in all your site. Ajax is generally used when you need to show some context change on one page, like posting a commner, faving a question, or things like that. Another great thing about it is not to bound user to a form (you can save info with a link like when you vote a question here)
Using GET or POST its usefull to let the user now here's moving along a process or when things that happen after or before are different, or context change a lot when submitting.
Rule of thumb (regardless of AJAX).
If you're going to send large amounts of data, or sensitive data... POST.
Otherwise, GET works just as fine.
I recommend use JQuery.
with $.ajax of Jquery, you can use it with multiple options depending that you need.
So you can work with POST, GET, receive data like text, json...
Here you can get more info:
http://api.jquery.com/jQuery.ajax/
I always use $_POST. I wish I could give a reason why I think it's better, but I can't. I guess it's because I've always preferred sending data via POST rather than GET so the user doesn't see it, and it just carried over to my ajax.
I would use $_POST just for the fact that it can store more data.
I have some variables set in Javascript. Further down the script I want to use these values in PHP. I realise I need to POST/GET them with jQuery, but I don't understand either function fully, even after looking at the manuals.
Could somebody break it down and explain the parameters?
Would I be better off using GET or POST in the instance?
Can the URL specified be the same as the current page e.g. index.php?
Thanks very much for your help.
You can not do this unless PHP is writing the javascript. PHP is on the server side and will be parsed before Javascript is ever seen by the client. Any variables set by JS will NOT be seen by PHP on the same request.
It's really just a question of style, really.
GET places all key/value-pairs in the URL field, whereas POST puts it in the HTTP body. Since URLs are limited in length, POST is preferred for longer, larger sets of data or data needing to benefit from TLS/SSL encryption.
So let's say we have a key: articleID. You want to pass 1 to articleID, so that the backend can contact the database and retrieve the article in question.
If you make a GET request, you'd invoke the following URL:
index.php?articleID=1
If you use POST, you'll put the data in the request body itself, so you wouldn't be able to tell what value you sent to the server without opening the packet in question and examining the request.
You'll find more information on how to perform these requests back at jQuery's reference site. More information about GET and POST.
You are the architect of the application, so you would know best what method to use. As for contacting the view itself, it's certainly possible albeit questionable from an architectural point of view.
How can I find the POST URL for a form that's being posted using ajax (action handlers are in PHP, but I doubt that matters too much in this case)?
Problem is I need to find out using an alternate method as I don't have access to the source.
if you can run the page, you could check with Live HTTP Headers or fiddler to see where the POST is going...
What do you mean you don't have access to the source? If the JavaScript Ajax call is executed, then you probably do have access to the code. It's probably just a bit tricky to find.
Use firebug to understand which request is happening.
I just started making a PHP/AJAX site and I was wondering where I should add the functionality to "only include the content".
Should I have if statements in my header and footer scripts that check for a "ContentOnly" get parameter? And then append that parameter to the query strings in my AJAX calls?
Or should I use a filter on the AJAX side to only grab the main content Div. Like in jquery:
$(this).load("/myPhpPage.php #mainContentDiv")
The first method would be faster right?
But the second method would keep the AJAX functionality on the presentation side, and out og my PHP.
Or is there a third method? I want to keep my PHP scripts intact, so that if oyu go to them directly, the header and footer are there. Thanks in advance!
Please don't use AJAX for the sake of using AJAX.
That said, most AJAX libraries pass a X-Requested-With HTTP header indicating that it's an AJAX request. You can use that header to decide whether to include your header/footer etc.
Depending on what paradigm you're using to handle page requests, I would generally recommend that you place such handling in the controller script. Handling view rendering logic that is specific to the type of request being made is entirely appropriate to place in the controller layer.
As ceejayoz suggested, you can use the X-Requested-With header (make certain that it is getting passed by your javascript library's ajax functions!) to verify in the controller script what the source of the request is and then render the view appropriately.
Adding to whats been said, your application shouldn't be aware of the rendered view. If you are making a call from javascript - javascript should know the context in which the call was made.
What this means is that the return handlers should know what they are handling during callback. The best method I've found for these types of transactions is to package objects in JSON that describe whats being called and who called it. Then when things are returned you can append some of these properties to the returned object. For instance if the same callback handler is used for everything you can simply pass the reference of the context back in this returned object.
Again though, don't use AJAX unless it serves a real purpose.
One place the X-Requested-With header came in very handy for me:
Very low-level authentication type method which would redirect to a login page... When requests are coming via AJAX, the redirect is a bad idea -- I want to return an XML payload with error response, so I throw an Exception for that instead. Yes, I could just have the authentication always throw, but then I have to implement handling that in every page and doing the redirecting there. Using X-Requested-With, I can get the best of both worlds.
X-Requested-With HTTP to indicate its a Ajax request is rather redundant. Ajax calls should never request HTML like the browser does!
In most cases AJAX calls shouldnt return html nor plain text. Make sure you specify the correct mime-type when doing the request to a page and have the page switch on the mime type used. This way when the browser request HTML it gets HTML when the AJAX call requests XML or JSON or if you must Plain text it will get the data in that format.
Edit: AHAH is a better term in this case indeed (technicality tho). I percieved content as data in the OP, which is why i was pushing mime-type so much.
I do however still think that getting ALL the content through ajax is a bad design, you lose more then you gain. It's better to go to a new page and expose some AJAX functionality within the content, IF needed.
And if that functionality AHAH's a small errorbox that doesn't need to be pushed in the history (which content does) for example so be it even my orthodox mind can live that :)
Even if you have a header which requires heavy calculation (i.e a treeview) there are other cache options that would benefit both the javascript-abled as -disabled as suppose only javascript-abled.
Thanks for the comments btw, i really did not want to come off as concieded but can see the note i struck was just that.