Comments
Thanks for the write up. I’ve been doing a bit of reading and it seems that including any javascript frameworks: jQuery, Prototype etc… is definitely not best practice and will potentially cause JS errors on the page the widget is embedded in. Is there any way to get the most out of jQuery while also protecting against unwanted conflicts?
Just wanted to add that the Hoptoad notification has been changed to the following:
HoptoadNotifier.notify(e)
I saw your name mentioned at http://blog.jquery.com/2010/02/19/jquery-142-released/ Feels proud. :-)
Note that all valid JSON structure is also valid JavaScript code so eval converts a valid JSON structure into a JavaScript object.
That’s a common belief; but it’s not entirely accurate: http://search.cpan.org/dist/JSON-XS/XS.pm#JSON_and_ECMAscript
You can replace the ‘expect’ calls from your tests, adding a second parameter in the `test` function:
test("name", 1, function() { ... });
Thank you very much. I was reading about associations in an ebook but it was very confusing there. You have made it very easy to study. Now, i understood it. Thanks very much again.
In fact, it works with every kind of parallel assignement like :
ar = [[:a, 1, 2, 4], [:b, 5], [:c, 6, 7]] d = ar.inject(0) do |sum, (first, *others)| sum += others.size end puts d #=> 6
For those who want more : http://ruby-doc.org/docs/ProgrammingRuby/html/tut_expressions.html#UC
Its really grt articule .actully i am written one sample app that insert in db with hibernate with session.flush() and close the app in seen that no record is added in Durby db but when i use session.close() bef that i found record is inserted in db thanks neerajdotname !!!
@Jean, you mention that the format.any works great in everything except IE. How do you get around the respond_to failure in IE?
Nice, that makes total sense now.. it never occurred to me until now that function($) was passing jQuery everywhere that you write $(’#something’) in your code in order to prevent library conflicts when you use NoConflict.
Now that I think about it, I’ve seen an extra precaution taken before: add a semicolon before the plugin pattern so that other, faulty plugins don’t interfere with your plugin. e.g.
;(function($){ ... })(jQuery);
This isn’t a jQuery feature, this is a JavaScript feature. Accessing properties on an object can be always be done as if accessing values on an associative array:
var foo = {
myField: 42,
myMethod: function() { alert("Foo!"); }
};
foo.myMethod(); // shows "Foo!"
//is the same as
foo["myMethod"](); // shows "Foo!"
// and
alert(foo.myField); // shows "42"
//is the same as
alert(foo["myField"]); // shows "42"
Thanks for the informative article. I recently ran into the issue when upgrading from jQuery 1.3 to 1.4, so needless to say I was a bit frustrated when “parsererror” started popping up out of nowhere.