0

UPDATE: OK, this turns out to be an encoding/decoding problem. In the actual SOURCE HTML, the ID is rendered as follows:

<input type="text" id="addInput0436%2E20_0" name="quantity" value="1" />

And the Javascript to reference it is rendered as follows:

javascript:app.catalog.product.updateAvailability('availabilityContainer0436%2E20_0','0436%2E20_0','PFC','0436.20', dojo.attr(dojox.html.entities.decode('addInput0436%2E20_0'), 'value'));

However, by the time the Javascript call gets to the dojo.attr() routine, the encoded value of addInput0436%2E20_0 has helpfully been decoded to addInput0436.20_0 which of course no longer matches.

So I need to either force the JS to not decode this string, or force HTML/Tomcat to not encode the HTML ID. Ugh.

ORIGINAL POST:

I'm trying to identify a problem with the following line of code:

document.getElementById('addInput0436.20_0')

This should return the DOM node with that ID (which does exist in the document) but instead returns null.

I suspect that it is the special character in the node name, but I'm not sure how to fix it. Anyone run into this before?

user3120173
  • 1,758
  • 7
  • 25
  • 39
  • Periods are valid in HTML ID values. http://stackoverflow.com/questions/70579/what-are-valid-values-for-the-id-attribute-in-html – isherwood Sep 16 '14 at 16:58
  • Can you provide a short, complete example that I could load as an HTML file in my browser? – apsillers Sep 16 '14 at 17:01
  • @isherwood As are underscores. However, some js libraries have problems with ids that contain periods because they are used as class selectors. Try escaping the period using a double backslash `\\ `. I don't know if it will work, but it's worth a try. – Enigmadan Sep 16 '14 at 17:03
  • Seems to work fine: http://jsfiddle.net/isherwood/be7uqg1f/ – isherwood Sep 16 '14 at 17:04
  • @isherwood Yup. Yours definitely works... Perhaps OPs ID is misspelled, incorrectly cased. Or perhaps OP is attempting to get the ID before the page is fully loaded. Is your JS at the top of your page? If so, try moving it to right before you close your body tag. Is your html validating? That's all I can think of... I hope one of them works for OP! – Enigmadan Sep 16 '14 at 17:19
  • periods are valid for sure, but there can be some annoyances. for instance if you pull in the value of an attribute like `name` that contains `"foo.bar.biz"`, the variable itself storing the value doesn't need any manipulation. but calling that value directly in the JS does need the `\\` as other comments point out. the annoyance is when you forget how you're referencing the value, either as a stored escaped variable, or an unescaped string. – Dpeif Sep 16 '14 at 18:13
  • Problem is that `%2E` is an url-encoded period, but since it is in an element's id, it shouldn't be treated as such. So I think the id is invalid because of the percent character. If you found out that the id in Javascript is translated to contain a period, then is looks like one of the functions you call explicitly url-decodes the string while it shouldn't. Two errors so it seems, unless this is intended behaviour. – GolezTrol Sep 16 '14 at 18:18
  • Yeah, it's definitely NOT intended behavior - still struggling with finding a solution, because this app is huge and I'm not sure what else will break if I change that ID. – user3120173 Sep 16 '14 at 18:22

1 Answers1

0

I'm posting this answer in case it helps someone else:

We finally resolved this by re-encoding the (previously decoded) tag ID inside the Javascript routine that needed it. We were not able to find any other way around this behavior.

Bottom line: Don't use URL-encoded strings as tag ID names. Doing so seems to be asking for trouble.

user3120173
  • 1,758
  • 7
  • 25
  • 39