Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#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 bill)

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)

currencybox-build-require.html (1023 bytes) - added by dante 11 years ago.
works with require() + build
currencybox-build-layers.html (753 bytes) - added by dante 11 years ago.
does not work with layer profile
currencybox-xd-1.1.1.html (1.0 KB) - added by dante 11 years ago.
xdomain example

Download all attachments as: .zip

Change History (14)

comment:1 Changed 11 years ago by dante

Description: modified (diff)

comment:2 Changed 11 years ago by bill

Component: GeneralDijit

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?

Changed 11 years ago by dante

works with require() + build

Changed 11 years ago by dante

does not work with layer profile

Changed 11 years ago by dante

Attachment: currencybox-xd-1.1.1.html added

xdomain example

comment:3 Changed 11 years ago by Adam 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.

comment:4 Changed 11 years ago by bill

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 in reply to:  4 Changed 11 years ago by Adam 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.

comment:6 Changed 11 years ago by 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.

comment:7 in reply to:  6 Changed 11 years ago by Adam 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.

comment:8 Changed 11 years ago by 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.

comment:9 Changed 11 years ago by bill

Component: DijitShrinkSafe
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 11 years ago by bill

Resolution: fixed
Status: newclosed

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.

comment:11 Changed 11 years ago by Adam 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.

Note: See TracTickets for help on using tickets.