#7183 closed defect (fixed)
CurrencyTextBox: Fails to validate after a build
Reported by: | dante | Owned by: | Adam Peller |
---|---|---|---|
Priority: | high | Milestone: | 1.2 |
Component: | ShrinkSafe | Version: | 1.1.1 |
Keywords: | Cc: | Adam Peller, Douglas Hays | |
Blocked By: | Blocking: |
Description (last modified by )
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.
Attachments (3)
Change History (14)
comment:1 Changed 13 years ago by
Description: | modified (diff) |
---|
comment:2 Changed 13 years ago by
Component: | General → Dijit |
---|
Changed 13 years ago by
Attachment: | currencybox-build-require.html added |
---|
works with require() + build
Changed 13 years ago by
Attachment: | currencybox-build-layers.html added |
---|
does not work with layer profile
comment:3 Changed 13 years ago by
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.
comment:4 follow-up: 5 Changed 13 years ago by
Description: | modified (diff) |
---|
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.
comment:5 Changed 13 years ago by
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.
comment:6 follow-up: 7 Changed 13 years ago by
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.
comment:7 Changed 13 years ago by
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.
comment:8 Changed 13 years ago by
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.
comment:9 Changed 13 years ago by
Component: | Dijit → ShrinkSafe |
---|---|
Owner: | changed from bill to Adam Peller |
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?
comment:10 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
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?