We Keep Coding

How to store variables for other jQuery scripts to use on the page.

I am trying to find the best methodology and have the cleanest code as possible on a project that I am working on.
I am using php and jQuery and displaying information on the page via ajax. When something changes on the page, some of the variables that are passed back into the page change. I need to store these values for other scripts on the page to use. What is the best approach for this.
Currently I am just storing these variables in hidden input fields with id's and then using jQuery to access them when needed. Is this a good approach or is there a better methodology? I don't want to have junky code that other developers look at and use and their punch line to their jokes.
Thanks!

I find storing the variables inside your script is faster, especially since you're using them with existing JS. I would go further than some of the comments, however. If you're working with a series of fields and methods, it's best to build a JS object and keep everything together. This has the added benefit of being viewable inside your DOM inspector (Firebug, etc).
function MyClass(obj) {
this.myvar = obj.val
}
MyClass.prototype.myFunc() {
console.log(this.myvar);
}
newobj = new MyClass({"val":1});
newobj.myFunc();

You can make use of HTML5 sessionStorage object
an example of how you set it
sessionStorage.setItem("myKey", "myValue");
please check documentation below
Here

Writing to a Firebase from within a Polymer element

I am working on an assignment for a course in "Coding the Humanities" which involves writing a custom web component. This means I am required to use Polymer even though as far as I can see there is absolutely no added value to doing so.
I want to create a literal chat "room" in which users input a character to identify themselves and can walk around the room bumping into one another after the fashion of robotfindskitten.
My idea was to write each character and its position to a Firebase location, updating everyone's positions in real time, so I need the Firebase JS client- using core-ajax for REST requests isn't fast enough.
The GitHub readme for the core-firebase element consists of a link to a less than helpful component page.
Looking at the core-firebase element itself, I don't see anything that corresponds to the 'value' event; locationChanged has a 'child-added' event handler, but that's it.
Am I crazy for thinking the core-firebase element is just very incomplete? Should I try to write my own 'value' handler? If so, do I just add it to the locationChanged property of the object passed to Polymer()? I'm very confused - I know enough JS that what's happening in the core-firebase code is straddling the limits of my comprehension. (Which might have to do with the this keyword, I don't know.) Any input here would be appreciated. (And yes, I've already remarked to the instructor that I could have handled this using plain old jQuery and Firebase if I didn't have to use Polymer. No word as yet on that.)

Looking at the commits for core-firebase it looks like it's had about two days work on it plus some maintenance, so it wouldn't be surprising if there are missing features.
One nice part about Polymer is that it interops very well with other ways of writing apps. It's totally reasonable and supported to use jQuery and Firebase directly to read from firebase and react to changes. You can still make good use of polymer's templating and databinding by doing this within an element of your own and using Polymer's data binding, templating, and plain old DOM events to propagate those changes throughout your app and render them onto the page.

JavaScript use custom attributes as persistance mechanism

I need to keep the state of my Html control (I've a multi select list and I need to keep the info about selected items), for which I'm using a custom attribute like:
// put
$("#element").attr("selectionState", "value");
// get
alert($("#element").attr("selectionState"));
While it works, I wonder if it's a safe approach and if not, how would you solve the problem?
The only risk I can see is - another script creating custom attributes with the same names, which is something I can manage.

I suggest using .data() instead.
$('#element').data('selectionState', 'value');
It's definitely safer, as it keeps the data completely in JavaScript instead of the "attributes" maps in the DOM elements. Sins ".data()" is all JavaScript, you can store anything there, including functions and closures. (I guess you could do that with ".attr()" too but it's pretty risky in IE, which, in old versions at least, had quite different storage management internally for DOM and for JScript.)
The namespace problem you allude to is of course the same, as would be the possible ways of managing it.

storing variables in html and using text()

I have a particular scenario where I need a file name, not once but twice, because I pass the variable to an ASP.NET MVC controller. Is it a good idea to either store the file name in a DOM element like a span or div, and getting the value by using jQuery's .text() function? Or would a better approach be to work with JSON-like objects that are initialized and then continuously manipulated?
The question however remains. Is it a good or bad idea to store variables in HTML DOM elements?

As #Atticus said, it's fine to do it either way, and I'll do both depending on what I need the data for: If it's specifically tied to the element, I'll store it on the element; if it's more general to the page, I'll pass back an object using JSON notation.
When storing data on DOM elements, you don't need to store them as text within the element. You can use data-* attributes instead. These are valid as of HTML5 and work in all browsers right now. The only downside is that if you're using validation as part of your workflow, and you're not yet using HTML5 to validate (and that wouldn't be surprising, the validator isn't quite ready, what with the spec still being rather in flux!), they don't validate in HTML 4.01 or below. But browsers are fine with them, this is one of the areas where HTML5 is codifying (and reigning in) current practice, rather than innovating.

Either one works, and it's fine to store data in a DOM. It more so depends on the complexity of the operation you are trying complete, which sounds simple -- storing file names. I think you should be fine doing it this way. Storing in JSON object works too, I would go with whatever fits your structure best and which ever works easier with your client/server handshake.

Use of jQuery.data

Well, I admit: I've extensively used jQuery.attr to store custom data in DOM elements in many, many scripts. I'm wondering if convert all my script to use jQuery.data instead of jQuery.attr. As far as I understand, the advantages of jQuery.data are:
produce neat and valid HTML code
can store any type of data (objects, array,...) on elements
The main advantage of custom attributes are:
If WEB pages are not strict HTML, I can produce HTML code with custom attributes on the server
In firebug it's easy to inspect my HTML code in search of my custom attributes
Can someone tell me if I miss something or if exists issues that makes use of jQuery.data highly preferable?

You pretty much got it. But do you know every HTML attribute? There are a lot of attributes that are used by screen-readers and other usability tools that are not standard (yet). What happens when you accidentally use the role attribute and a screen-reader picks that up? Using $.data isn't only neater, it's safer for you and makes more sense.
EDIT: I learned something last night that is pertinent to this question. In HTML5, you ca specify custom attributes for storing data. These custom attributes must be specified using the prefix "data-". See the spec for more detailed information.
What this means, is that you do not have to go back and change all of your old code, because you will never have to worry about overlapping with other attributes if you prefix with "data-". However, if you need to store more complicated data types than strings, use $.data.

I think that you don't miss anything but storing data on dom elements attributes is always a bad practice so i think you should use the $.data function.