Personally, I used Drupal.settings
as a read-only object for communicating settings and configuration information from PHP to JS. Runtime state isn't appropriate here.
jQuery.data()
should only really be used to pull out data attributes that you have set via PHP, and for setting data that is specific to that element-only.
Runtime logic and state should be stored in its own closure. I use a variant of the Javascript Module Pattern, which I have adapted for Drupal. Boilerplate looks like:
var FOO = (function(me, $, Drupal, undefined) {
me.name = "FOO";
// local properties
var foo = null;
var bar = null;
// local functions
function somethingAwesome () {
console.log(me.name + '.' + arguments.callee.name + '()');
}
// global properties
me.baz = null;
// global functions
me.somethingAwesomer () = function somethingAwesomer {
console.log(me.name + '.' + arguments.callee.name + '()');
};
// Drupal
function init (context, settings) {
if (settings.foo) {
console.log(me.name + '.' + arguments.callee.name + '()', $.fn.jquery);
// do stuff
}
Drupal.behaviors[me.name] = undefined;
};
Drupal.behaviors[me.name] = {
attach: init
};
return me;
}(FOO || {}, jQuery, Drupal));
I don't do a lot of true behaviors, though, hence making my initialization function a oneshot.