Using ExtJS 2.2.1, I've got a container element which is supposed to load a piece of HTML from the server using:
autoLoad: { url: 'someurl' }
This works fine in Firefox, but for IE7 this results in a syntax error in ext-all-debug.js at line 7170:
this.decode = function(json){
return eval("(" + json + ')');
};
I fixed this by turning that function into this:
this.decode = function(json){
return eval('(function(){ return json; })()');
};
Then the autoLoad works well in both browsers, but then there's some odd bugs and besides, you really don't want to fix this in the ExtJS library as it will be unmaintainable (especially in the minified ext-all.js which is like half a megabye of Javascript on a single line).
I haven't been able to find a lot about this bug.
Variations that I've tried:
// With <script> tags around all the HTML
autoLoad: { url: 'someurl', scripts: true }
// With <script> tags around all the HTML
autoLoad: { url: 'someurl', scripts: false }
And visa versa without the <script> tags. There isn't any Javascript in the HTML either, but it should be possible, because eventually we will use Javascript inside the returned HTML.
The problem isn't in the HTML because even with the simplest possible HTML, the error is the same.
UPDATE - Response to donovan:
The simplest case where this is used is this one:
changeRolesForm = new Ext.Panel({
height: 600,
items: [{ autoScroll: true, autoLoad: WMS.Routing.Route("GetRolesList", "User") + '?userID=' + id}]
});
There is no datastore involved here. The response-type is also text\html, not json, so that can't be confusing it either. And as said, it's working just fine in Firefox, and in Firefox, it also executes the same eval function, but without the error. So it's not like Firefox follows a different path of execution, it's the same, but without the error on eval.
Check your JSON. FF allow trailing commas in JSON objects while IE does not. e.g.
{foo:'bar',baz:'boz',}
would work in FF but in IE it would throw a syntax error. In order for there to not be a syntax error the JSON would need to be:
{foo:'bar',baz:'boz'}
I located the source of the problem and it was indeed not with ExtJS. There was a section in the application that listened to the Ext.Ajax 'requestcomplete' event and tried decoding the response.responseText to json, even if the response was HTML (which it only is in one or two cases). IE was not amused by this.
If you're autoLoad'ing into a Panel or Element then a JSON decode shouldn't even be involved in the process. UpdateManager just defers to Ext.Element.update(..) which takes a string of html.
The only reason I can think that your response would be parsed as JSON is if you were using a JSONStore to request it - what are you using?
You should be able to do something simple like this:
var panel = new Ext.Panel({
autoLoad: 'someurl' // this is the short form, you can still use the object config
});
OR
var element = Ext.get('element id').update({
url: 'someurl'
});
Response to Update:
That looks correct as long as something weird isn't happening with the WMS.Routing.Route(...) method. I'm actually currently working on an ExtJS application myself so I was able to quickly test some different server responses and couldn't reproduce your problem. I've also relooked at the ExtJS 2.2.1 sources and still see nothing in the related Element update and UpdateManager that would make the call to Ext.util.JSON.decode(...) that you're seeing.
I'm imagining that its from an unrelated AJAX request in another part of your application. If you're not already, I would use firebug / firebug lite to help debug this - specifically try to get a stack trace to make sure the source of your problem really is this autoLoad.
I had the same problem, excuse my english, i'm from Mejico, i hope I can help… my problem was triggered when I submit a Form to login, my PHP returns a JSON with the response in case of failure like this:
$respuesta = "{success: false, msgError: 'El usuario o contraseña son incorrectos'}";
but I wasn't send a resposne when it success, well when it has a true success, then the ExtJS it was trying to decode my JSON response, but there was nothing to decode, i guess that was, in my case again, the problem… I solved just sending back a response for the true succes, FF, Chrome, Safari, dont catch the problem, but Opera and IE8 does… I hope I help someone, goodbye
I don't know what the problem is, but I wanted to point out that your "fix" makes it simply return the json as a string instead of an eval'd object, so of course there is no error anymore -- you removed the functionality. It could just as simply be:
this.decode = function(json){
return json;
}
Generally speaking, random errors like this do not usually indicate a bug in Ext, especially not in functions used as commonly as Ext.decode. I would guess that either there is something in the JSON that IE does not like that other browsers ignore, or more likely, there is something unexpected going on in your app that is not obvious from your description. Have you tried inspecting your request log in Firebug to see what the JSON actually looks like? Have you tried getting the result of your Route call into a variable first to verify its contents before populating the panel? Also, try setting the "break on all errors" option in Firebug to true -- a lot of times when you get a random function from Ext at the top of your stack trace, the culprit is actually some application code that you weren't expecting.
Related
I have built a form to add some dummy data to a Mongo collection for testing purposes. The function to add the data seems to be working ok in that the data is being added ok, but, for some reason, the redirect command at the end of the function is not doing its thing. The data comes from a bog standard HTML form. Here is the code for adding the data:
router.post('/addacc',function(req,res){
var sljEdate = "";
var pljEdate = "";
var MongoClient = mongodb.MongoClient;
var url = 'mongodb://localhost:27017/stc';
MongoClient.connect(url,function(err,db){
if(err){
console.log("Connection Error");
}else{
console.log("connected to mongo");
var collection = db.collection('account');
var query = {accountID: req.body.acc_id,companyName: req.body.acc_name,companyEmail:req.body.acc_email,companyPhone:req.body.acc_phone,companyPostCode:req.body.acc_postcode,
photographers: {phtID:"",phtName:"",phtPhone:"",phtEmail:"",phtLoc:"",preferredContact:"",lastJob:"",pljEpoch:pljEdate,phtNotes:""},
schools: {schoolID:"",schoolName:"",schoolPhone:"",schoolEmail:"",schoolPostCode:"",lastJob:"",sljEpoch:sljEdate,notes:""}};
collection.insert(query,function(err,result){
if(err){
console.log("Error inserting Account record",err);
}else{
console.log("Data Insert Success");
res.redirect("/forms");
}
db.close();
});
}
});
});
I added lines to log to the console in a few places so that I could check progress and they all fire, including the final 'Data Insert Success' one. The res.redirect which follows it, however, does nothing. In the browser the URL remains as '/addacc', though the node console shows a subsequent GET for the '/forms' URL.
I've tried a few variations for the redirect, using e.g. res.send("test") just to try and output something, also a res.render function, but none of them seem to work.
I'm pretty sure that I have missed something simple, but I've been staring at the code for too long and I can't see anything wrong with it. In fact, I've had nearly identical code working lots of times. The only thing I'm doing differently this time is that I'm inserting into a Mongo collection which includes embedded documents, but the data insert is not the problem as the data gets in fine.
Help please!
Ok, it seems that the Node problem above was a bit of a red herring. The redirect is actually working ok (MrWillihog's comment above is duly noted for future reference anyway). I thought it must be as all the response codes on the npm console checked out fine. The problem is actually to do with the rendering of the Jade template. Specifically something to do with the the file layout.jade which I use to set out the HTML head. For some reason (yet to be determined) things work fine when calling the /forms page directly in the URL. The file forms.jade starts in the standard way with
extends layout
block content
With the opening BODY tag in layout.jade the page fails to load properly when called from the redirect: the layout.jade file renders (I put an H1 in there to check), but forms.jade doesn't.
I moved the BODY down in to forms.jade (under block.content) and it started working though, interestingly, the URL in the address bar remains as '/accadd'
Again I'm a bit stumped as I have used this pattern quite a few times with no issue. I'm guessing that I've just forgotten something simple. I'll keep digging until I find the answer, but at least now I should be looking in the right place.
I searched around, and couldn't find an answer to my question. I'm very new at coding, and at work, we have an application that current names that are logged in, and what they are doing.
Recently, they have changed from jquery 1.4.1 to jquery 1.8.3. Ever since then, I cannot get the results to process correctly, because of the following error;
"Unable to get value of the property 'split': Object is null or undefined"
I have the code setup to grab the results and split them;
function processAgents(xData, status) {
var avail = xData.responseText.split("|")[0];
var acw = xData.responseText.split("|")[1];
var total = xData.responseText.split("|")[2];
var breaks = xData.responseText.split("|")[3];
var pending = xData.responseText.split("|")[4];
The application is setup to open as an HTA file which opens up the PHP script.
Any help would be appreciated, please let me know if I left anything out!
Thanks!
EDIT 1
I did some more investigating, and it looks like I'm not getting data from my process request. This is how it is currently setup
function updateAgents() {
var ts1 = new Date().getTime();
$.ajax({
url: "http://SERVER/AgentSrc.php?x=" + ts1,
complete: processAgents
I'm not sure if this is processing correctly since they went to jquery 1.8.3.
EDIT 2
So after looking into it more, it doesn't appear that the script is getting the data from the server, even though I have access. If I make a local file and put the information in it, it will pull the information and split it, but if I point to the path of the file on the server, it won't get the information. But the strange thing is, if I run it using jquery 1.4.1, it pulls the data fine, but can't display it. But with 1.8.3, it doesn't allow me to pull it from the server.
thanks again!
This will give some clarity
xData.responseText.toString().split("|")[0];
(split is part of string not jQuery)
Here is a possible explanation: in earlier versions of jQuery, ajax calls returned an xmlHttpRequest (XHR) object. Recent versions return a promise (jqXHR) instead.
See this page for more details.
I have been struggling since yesterday with the following piece of code.
function findLocation(){
alert(1);
$.getJSON( "http://www.omc4web.com/geoip/geoip.php",
{ip: "127.0.0.1",
callingurl: "www.thissite.com" },
function( result ){
alert(2);
$.each(result, function(i, field)
{
alert(i);
if(i=="country")
{
country_code = field;
}
});
})
}
It does not seem to want to get beyond the calling of the php script. The returned data is {"country":"US","store":"US"} but the function does not seem to want to process it and I never get to alert(2). I have placed monitors in the php script and I can see that it does indeed get called with the correct parameters and it does return the data expected.
if you call http://www.omc4web.com/geoip/geoip.php?ip=127.0.0.1&callingurl=www.thissite.com from your browser you will see that data is returned.
The same piece of code calling a URL with no parameters behaves correctly, but not with the above setup.
My few remaining hairs would appreciate some help on this.
additional info:
header('Content-type: application/json'); set on php script
tried it on chrome and firefox
no errors show up on firebug just a blank response screen
running script from localhost, but if its a cross domain issue, why am I able to make a similar call (without params) to amazon? $.getJSON("http://freegeoip.net/json/",function(result){ works fine as does the popular flickr example.
I am using <script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
Thanks in advance
Ossi
I think it's a cross domain issue. I guess you're able to use freegeoip.net because you're using JSONP. Try looking at the jQuery documentation to learn how to use JSONP: jQuery.getJSON()
Here's some simple Javascript:
(function($){
var ajax_callback = function(data) { window.location.hash = data.h1; };
$('.clickable').live('click', function() {
$.post('server.fcgi', {}, ajax_callback, 'json');
}
);
})(jQuery);
The server is a c++ binary (yes, i know) that spits out (through fast_cgi) the string:
{"h1":"newhash"}.
The expected behavior is that the URL should change.
Instead, nothing happens and Firebug complains that 'data' is "null"!.
Any help would be greatly appreciated!
Will.
When the following code enters "ajax_callback", it says that "data" is "null"!.
But the server is a c++ binary that is confirmed to return the JSON string {"h1":"newhash"}.
Anyone have an idea why JQuery seems unable to accept the JSON data when calling the ajax_callback?
I did have similar problem as you have mentioned when using $.POST().
There are two things if you are using jquery $.post method. You need to add an extra bracket before defined data type ("JSON") as shown below. I don't know why but it works, it will return data.
$.post('server.fcgi', {}, ajax_callback,{}, 'json');
The second thing is that you will need to parse JSON data using $.parseJSON(data) in side the callback function.
One more thing to make sure that the url to fetch JSON, the page document type should be defined as JSON in the header.
I have given an example below.
$.post("url/path/here/to/json", {}, function(data){
if(data){ // just in case the called program had a problem
var obj = $.parseJSON(data);
.... do everything else using the Obj->
}
},{},"json");
This will work.
However I recommend to you to use another Jquery function specially implemented for JSON, that is called
$.getJSON();
Here is the url for more information
And I am suggesting you to use the following method instead of the one described by you.
$(document).ready(function(){
$('.clickable').live('click', function() {
$.getJSON('server.fcgi', function(data){
window.location.hash = data.h1;
});
}
);
});
Make sure the server also returns the correct HTTP headers before the payload. E.g.:
HTTP/1.0 200 OK
Content-Type: application/json
Content-Length: ...
...
{"h1":"bla"}
From your description, I could not quite make out if all it did was printf("{\"h1\":\"bla\"}"); or not.
To check the actual result, use a command line tool like HEAD, GET, wget, curl, or even nc. If you are not able to use one of those, you might get some clues from the Net panel in Firebug and the like.
Probably not the answer you want to hear, but I assume you're using jQuery 1.4.2? I noticed that this does work as expected in 1.3.2 so you might want to consider using that instead. :(
We have had some reports of problems with our checkout whereby customers get js exceptions (we assume) so they cannot checkout.
No matter how many testbenches we use, we have failed to recreate the issues but that's the point of the exercise.
I have setup a simple error trapping function which works based around:
window.onerror = function(message, url, line, chr) {
new Request({
url: "/errorTrap.php",
data: {
m: message,
u: url,
l: line,
c: chr
},
method: "get",
onComplete: function() {
// perhaps save the rendered html source via a second POST request?
alert("done");
}
}).send();
return true;
};
Sure enough, in a single week I have now received 8 emails of trapped exceptions.
Regretfully, the checkout page is very dynamic. It contains SOME inline javascript, a lot of it is external .js files and classes and some is evaluated js through ajax responses. The length of the page differs dependent on items in the shopping basket, shipping options, address book info and so forth.
This is why seeing an exception 'Object expected' on line 253 means very little as it does not help me understand which function has triggered the exception or supply the context of the script block / source code that goes with it.
I have been thinking of doing a second XHR request that can drop the innerHTML of document.body to a ajax handler and thus supply a relative line numbering and content that may have caused the problem.
Is this the only improvement in tracing I can do? Are there any solutions for this "out there"?
Here is the jsfiddle that demos the exception handling http://www.jsfiddle.net/dimitar/8hqrY/
Well, debugging a problem is always like that. Either going there, actually seeing the issue and then tackling it with debug tools or getting evidence, guesswork, getting more evidence and so on, Sherlok Holmes-style :^)
In addition to DOM tree, you can get JS stack trace: A Javascript stacktrace in any browser.