CurrencyTextBox: Fails to validate after a build

[dante]

Using the sample markup:

<input id="textboxtab-currencybox" name="textboxtab[currencybox]" value="" 
type="text" currency="USD"
invalidMessage="Invalid amount. Include dollar sign, commas, and cents." 
constraints="{'fractional':'true'}" required="1" dojoType="dijit.form.CurrencyTextBox" />

(and other tested variations of constrints and symbols, currencytextbox fails to validate properly, but only after a build.

This issue can be seen (and has been verified) against AOL Dojo 1.1.1, 1.1.0, a trunk build as of 7/14/08 ... It only works properly with an unbuilt Dojo. More specifically, it seems to work when CurrencyTextBox is NOT included in a layer. Eg: dojo.require the textbox seems to work, but loading it as part of a layer does not?

To reproduce: Type in the box using a layer: "$1,000.00" .. The validation only goes away with non-build, or isolated dojo.require

Marking 1.2 for now as it seems a serious shortcoming, feel free to do with as you choose. I've not the foggiest idea where to being investigating this. A workaround would be awesome.

[bill]

I'm confused. $1,000.00 is a valid string; why would you expect a validation error? Or is the problem that CurrencyTextBox rejects that value as invalid?

[dante]

works with require() + build

[dante]

does not work with layer profile

[dante]

xdomain example

[peller]

It appears to be an encoding problem, at least with the xd case. If I insert

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

into the head, it works fine. AOL should be serving up all the content as UTF-8 by default, if they can. Better still, I'd like to get the BOM marks working (#4661) on the build, but can't figure out how to insert them with our tools.

[bill]

I suspect this is already fixed by [14271], although that was IE only so there's a bit of a mystery. I don't think you should need that <meta> tag unless the main index.html page itself has utf-8 characters.

[peller]

Note that the same workaround fixes the non-xd case, and if I'm not mistaken, non-xd uses XHR instead of script-io. XHR should have no problem defaulting to utf-8, so I don't understand what's happening here.

Also, to follow up on my earlier note, while it would be best to manage the BOM stuff, the AOL CDN fix may be required to get legacy versions working properly.

[bill]

We should probably check the headers on the response from AOL, maybe they should specify encoding and they don't. Something like http://ws.geonames.org/cities?north=44.1&south=-9.9&east=-22.4&west=55.2&lang=de&style=full has an encoding in the response header.

[peller]

Replying to bill:

We should probably check the headers on the response from AOL, maybe they should specify encoding and they don't.

Right, that's what I meant, above. James and I have discussed this, but it's difficult to do since it requires ops. Either way, we've got a problem with non-xd builds.

[bill]

For XD builds, this is already fixed. AOL is doing something bad because their response doesn't specify an encoding. (Look in firebug's NET tab comparing http://o.aolcdn.com/dojo/1.1.1/dojo/dojo.xd.js to the link above)

However, after [14271] that's not an issue.

Will look at non-XD case next.

[bill]

I did a build... it works fine when using myLayer.js.uncompressed.js, but fails with myLayer.js, so it's a shrinksafe problem. And, the workaround is to use the uncompressed file.

Failure seems to be on this line from dojo/base/number.js:

var isCurrency = pattern.indexOf('\u00a4') != -1;

(with the unicode character getting garbled). There might be another open ticket about this.

Peller, can you work on this?

[bill]

Oh, actually, my comment above is inaccurate. Shrinksafe is working correctly. There's an open ticket to skip over compressing \u00a4 into a unicode character, but that's more of an enhancement.

In the end, the developer needs to have charset="utf-8" on all their script tags, and then this works correctly.

[peller]

see #6628 for compression enhancement.

see also #4661 to add BOM sequence to files, which, if supported everywhere, would make the charset unnecessary and help with some tooling.