Multiple reuse results in hidden form elements

[GoogleCodeExporter]

Explanation:

I have a google maps mashup using ExtInfoWindow. I'm using the AJAX pull 
of each window's contents. These contents include three rating areas. The 
first popup works fine. All subsequent popups have hidden star ratings 
(i.e. they can't be seen).

I've examined the FireBug output and see that there has been no insert of 
the star class stuff that you build in your plugin.

My guess is that when I call .rating() the second time, the plugin 
says "hey I already did this" and ignores it. I attempted to add a 'reset' 
method to the plugin, but honestly, I don't do jQuery plug-ins well at 
this time. My hack didn't work, thus I am reporting it.

It's not a bug per-se, but it will not work in the way I'm trying to use 
it. Any help with this would be most appreciated.

What version of the plugin/jQuery are you using?
PLUGIN VERSION: latest
JQUERY VERSION: 1.3.1

On what browser(s) or operating system?
BROWSER(S): IE & FF

Please provide a link to where the problem can be observed:
URL: http://jablan.is-a-geek.com

Feel free to provide any additional information below.

Original issue reported on code.google.com by jerryab...@gmail.com on 13 Apr 2009 at 11:32

[GoogleCodeExporter]

I wanted to add a follup to this. I have found a workaround.

What I've done is append each <input> tag's name with a unique ID for that 
block. 
This fixes the non-display issue. However, I can imagine that it will 
eventually run 
out of memory and crash.

Just wanted to update you.

Original comment by jerryab...@gmail.com on 13 Apr 2009 at 11:44

[GoogleCodeExporter]

Another follow up, sorry.

The workaround works for any window except the first.

Here's what's happening:

1. I make an AJAX call to get a popup window contents that includes the rating.
2. I call $().rating(), which applies the style, injects the new html and hides 
the 
inputs.
3. jqRating stores the information and notes that this particular element has 
been "converted"
4. I close the popup
5. I re-open the same popup, getting the info from AJAX again, new INPUTs but 
same 
IDs and NAMEs.
6. I call $().rating(), which DOES NOT apply the style because it has cached 
the 
fact that IDs and NAMEs have had the star style applied.

Make sense?

I'm looking for a way to clear that cache....

Original comment by jerryab...@gmail.com on 14 Apr 2009 at 2:47

[GoogleCodeExporter]

Hey there. I patched the code to get around my problem. Not sure you've looked 
at it 
yet.

Here's what I did:

1. Created a new option called 'resetAll', boolean:

resetAll: false, // Forces a reset when loading...

2. I changed the declaration of 'raters' to look at 'resetAll':

var raters = ( options.resetAll ? { count:0 } : context.data('rating') || { 
count:0 } );

3. Lastly, right after all the variable declarations, I set 'resetAll' to false:

options.resetAll = false;

This seems to work just peachy. As I stated earlier, I'm not sure if this will 
result in memory leakage over time, but JS is supposed to GC right?

Original comment by jerryab...@gmail.com on 16 Apr 2009 at 4:38

[GoogleCodeExporter]

Sorry, here's my copy of the code...

Original comment by jerryab...@gmail.com on 16 Apr 2009 at 4:40

Attachments:

• jquery.rating.js

[GoogleCodeExporter]

Hi Jerry,

Thank you for your efforts to resolve this issue and thank you very much for 
reporting your progress. The root of the problems here seem to be that you're 
"not 
quite" using valid markup.

1st: all input elements must have a 'name' parameter - the plugin depends on 
this in 
order to identify/separate element sets. it would not be sufficient for the 
plugin to 
generate unique names because there is not safe way of assuming where a set of 
radio 
buttons begins/ends unless they have 'name'.

2nd: you may have several group with the same 'name' parameter on the same 
page. the 
plugin differentiates between these groups by caching the control settings on 
their 
containing form (the form the elements belong to) - this is the scope of the 
plugin. 
In this case, your problem is that you are not inserting the input elements 
within a 
form. And because of that, the plugin stores the controls setting  on the body 
tag - 
this then becomes the scope of the plugin.

Your patch will work. As you correctly pointed out, there is a risk it could 
create 
huge memory leaks over-time (specially in an application such as yours) but I 
doubt 
this will be the case. That's because whatever settings were stored about the 
old 
plugin will be overwritten by the new plugin (of your second call).

However, your fix may create an even bigger problem. If you use the resetAll 
parameter to create a new control with the same name, but the previous control 
has 
not yet been removed, the first control would stop working because its settings 
in 
the container would be replaced with the new settings (and functionality).

It works for you because you are replacing the html (and removing the previous 
elements) but it cause problems if you were appending the code.

But, I think there's a way of doing this automatically, without the risk of 
breaking 
previously created plugins. And the method is to make each call to the plugin 
unique 
by adding a serial number to the internal control ID.

This way no additional settings will be required (no user input) and we save a 
little 
code... I'll post back when it's ready!

Original comment by diego.a...@gmail.com on 16 Apr 2009 at 8:54

• Changed state: Started

[GoogleCodeExporter]

Done! Please follow the twitter account for future updates:
http://twitter.com/fyneworks

Original comment by diego.a...@gmail.com on 16 Apr 2009 at 9:27

• Changed state: Done