Here's my issue, I'm trying to load a FB comments module via an AJAX div. Now, it works if I go directly to the php page, but if I load it from within the div, it doesn't. I've looked at the other posts (FB javascript SDK after jquery LOAD (ajax)), but still can't seem to get it to work, looking for clarification.
If you want to see what I'm talking about, check http://azconceptphoto.com/lindsey and check out testimonials.
Ideally, on the normal part of my site, I can just load the HTML5 code and it works fine, though for some reason it doesn't remotely work via the AJAX div. And considering the posts from before are out of date (2011), I was hoping to get more feedback on this.
Based on the code from your link you are not using any of the PrototypeJS Ajax methods to get the backend script. Ajax.Updater is the method you need to use so....
Here is my suggestion
change the definition of loadXMLDoc() to
function loadXMLDoc(div, location)
{
new Ajax.Updater(div,location,{'evalScripts':true});
}
this will update the contents of div with the contents of location. Also if the response has <script> tags in it then the javascript will be parsed and evaluated (thats the option evalScripts)
I've two php-scripts: the first makes ajax call to the second, which returns javascript code and div for swfobject. I'm calling the second file twice: after loading page(it works ok and I can see swfobjects) and after users' clicking on button(it not works and div just goes blank).
I suggest that embedSWF works ONLY after pages' loading, because my ajax calling is correct.
But a way must be found! Any ideas?
Yes, swfobject.embedSWF is designed to work after page load -- it has a built-in domload event handler.
If you don't want swfobject to automatically embed when the page is loaded, use swfobject.createSWF instead. The official documentation explains how swfobject.createSWF works.
EDIT:
After re-reading your post, I see you want to embed a SWF after the page has already loaded. swfobject.embedSWF can be used in both cases. Here's a tutorial and an example.
I've search high and low for an answer to this but unfortunately I'm stuck. The problem is only occuring in Firefox (tested IE, Chrome and Safari also - works fine, no errors of any sort). I'll detail the sequence of events to save posting all my code.
ASP.NET MVC 3 application, basic form loads into a jQuery UI dialog
Custom jQuery to hijax the form submit (serialize the form and then $.post to the server - no compiler errors when debugging and post shows up in Firebug without errors)
Http GET (automatically happens) getting the response object from the server (+ success text and XHR), response is plain HTML in this case (again, shows up in Firebug with no errors)
Custom jQuery to change the HTML of the UI dialog from it's current HTML to the response Html - this is where it fails.
I've used javascript alerts to debug the sequence of events and as soon as the post (and get) is complete, everything just... sort of stops.
As I say, only in firefox! Very odd, just wondering if there's any known bugs with ajax and firefox or anybody has heard of a similar situation?
I must also add, that on other parts of my site, this works perfectly in all browsers! The only difference between this form and the other forms that do successfully complete the function is that the response from this form is the same "page" again but updated rather than a new "page". (I use "page" as I got all this working with Javascript turned off first and for graceful degredation)
HELP! Or laugh, either is fine.
UPDATE
I have tried sending a view with a blank model back as the action result - works in every browser except firefox - firefox retains the values from the previous post! And then I got to thinking - that's a trait of firefox isn't it? And maybe that's why the original "re-direct" html response doesn't work?? I think it's time to give up and let people know they can't use Firefox for that particular function!
Ok so I'm answering my own question.
The only way I found to get round it is to use $.ajax instead of $.post and to use the option async : false
Hope this helps somebody.
Rob
Have you tried adding the attribute [OutputCache(Location = System.Web.UI.OutputCacheLocation.None)] to your Action for your GET? It sounds to me like a caching issue.
HTML/JS Here: http://pastebin.com/JrtfeAtw
PHP Here: http://pastebin.com/EcRHCwmY
Based on Ajax F1's tutorial here: www.ajaxf1.com/tutorial/ajax-file-upload-tutorial.html
Anyway, my problem. In Chrome, this works fine. However, in Firefox, it will upload the first file no problem, and begin uploading the second one. I've traced it in Firebug and it definitely calls form.submit() on the correct form, and the form has the correct fields in it, but for some reason my form never gets submitted.
Is this because I'm submitting the same form twice? And if so, is there a workaround that anyone knows of?
Cheers!
I have no explanation for this, however, setting the source of the iFrame to about:blank between each image upload fixed the issue.
I'm writing an AJAX app, but as the user moves through the app, I'd like the URL in the address bar to update despite the lack of page reloads. Basically, I'd like for them to be able to bookmark at any point and thereby return to the current state.
How are people handling maintaining RESTfulness in AJAX apps?
The way to do this is to manipulate location.hash when AJAX updates result in a state change that you'd like to have a discrete URL. For example, if your page's url is:
http://example.com/
If a client side function executed this code:
// AJAX code to display the "foo" state goes here.
location.hash = 'foo';
Then, the URL displayed in the browser would be updated to:
http://example.com/#foo
This allows users to bookmark the "foo" state of the page, and use the browser history to navigate between states.
With this mechanism in place, you'll then need to parse out the hash portion of the URL on the client side using JavaScript to create and display the appropriate initial state, as fragment identifiers (the part after the #) are not sent to the server.
Ben Alman's hashchange plugin makes the latter a breeze if you're using jQuery.
Look at sites like book.cakephp.org. This site changes the URL without using the hash and use AJAX. I'm not sure how it does it exactly but I've been trying to figure it out. If anyone knows, let me know.
Also github.com when looking at a navigating within a certain project.
It is unlikely the writer wants to reload or redirect his visitor when using Ajax.
But why not use HTML5's pushState/replaceState?
You'll be able to modify the addressbar as much as you like. Get natural looking urls, with AJAX.
Check out the code on my latest project:
http://iesus.se/
This is similar to what Kevin said. You can have your client state as some javascript object, and when you want to save the state, you serialize the object (using JSON and base64 encoding). You can then set the fragment of the href to this string.
var encodedState = base64(json(state));
var newLocation = oldLocationWithoutFragment + "#" + encodedState;
document.location = newLocation; // adds new entry in browser history
document.location.replace(newLocation); // replaces current entry in browser history
The first way will treat the new state as a new location (so the back button will take them to the previous location). The latter does not.
SWFAddress works in Flash & Javascript projects and lets you create bookmarkable URLs (using the hash method mentioned above) as well as giving you back-button support.
http://www.asual.com/swfaddress/
The window.location.hash method is the preferred way of doing things. For an explanation of how to do it,
Ajax Patterns - Unique URLs.
YUI has an implementation of this pattern as a module, which includes IE specific work arounds for getting the back button working along with re-writing the address using the hash. YUI Browser History Manager.
Other frameworks have similar implementations as well. The important point is if you want the history to work along with the re-writing the address, the different browsers need different ways of handling it. (This is detailed in the first link article.)
IE needs an iframe based hack, where Firefox will produce double history using the same method.
If OP or others are still looking for a way to do modify browser history to enable state, using pushState and replaceState, as suggested by IESUS, is the 'right' way to do it now. It's main advantage over location.hash seems to be that it creates actual URLs, not just hashes. If browser history using hashes is saved, and then revisited with JavaScript disabled, the app won't work, since the hashes aren't sent to the server. However, if pushState has been used, the entire route will be sent to the server, which you can then build to respond appropriately to the routes. I saw an example where the same mustache templates were used on both the server and the client side. If the client had JavaScript enabled, he would get snappy responses by avoiding the roundtrip to the server, but the app would work perfectly fine without the JavaScript. Thus, the app can gracefully degrade in the absence of JavaScript.
Also, I believe there is some framework out there, with a name like history.js. For browsers that support HTML5, it uses pushState, but if the browser doesn't support that, it automatically falls back to using hashes.
Check if user is 'in' the page, when you click on the URL bar, JavaScript says you are out of page.
If you change the URL bar and press 'ENTER' with the symbol '#' within it then you go into the page again, without click on the page manually with mouse cursor, then a keyboard event command (document.onkeypress) from JavaScript will be able to check if it's enter and active the JavaScript for redirection.
You can check if user is IN the page with window.onfocus and check if he's out with window.onblur.
Yeah, it's possible.
;)