can any one explain why(how) the xtype: numberfield value is going to auto correct(change) if am providing more than a 16 digits value.
For Example:
22222222222222222 is changed to 22222222222222224
222222222222222222 is changed to 222222222222222200
2222222222222222222 is changed to 2222222222222222300
22222222222222222222 is changed to 22222222222222220000
222222222222222222222 is changed to 222222222222222230000
2222222222222222222222 is changed to 2.2222222222222222e+21
22222222222222222222222 is changed to 2.2222222222222223e+22
Which results in my page after rendering as shown below when get the value through in my component jsp page
NumberFieldTestValue:<%= properties.get("numberfieldname","") %>
Resulting as below
NumberFieldTestValue: 2.2222222222222223e+22
The problem
This behavior is caused by the fact that the dialog behavior is implemented in JavaScript. The numbers you're having problems with cannot be represented in it.
The language conforms to the ECMASCRIPT 5.1 specification.
To quote the Number type description
all the positive and negative integers whose magnitude is no greater
than 2^53 are representable in the Number type
The base 2 logarithm of 2222222222222222222222 is about 70, which means the number exceeds the maximum value. Hence your problems.
All in all, if you check your examples in a plain JS console in a browser, the same behavior will be displayed so this is not really a CQ problem.
Solution 1 - use a different type
To avoid this, you could potentially use xtype="textfield" and validate it against a regular expression to see if it consists of numbers only. Then you'd have to make sure to use a type capable of holding such numbers at the backend (like BigInteger).
The field could look like this:
<numberOfSandGrains
jcr:primaryType="cq:Widget"
fieldLabel="Number of grains of sand at the beach"
name="./grainsCount"
regex="/\d+/"
regexText="Please enter a numeric value."
xtype="textfield"/>
Solution 2 - change scale
Another option is to change the logic behind the configuration and use some different units if applicable. For instance, if the value 2222222222222222222222 is a number of grams (weight of an object/substance), it makes perfect sense to read it in metric tons instead (at least in many cases). The author could probably do without entering such humongous numbers.
You'll need to be extra-careful if you go this way.
Related
I am implementing an input, where the user should type number in the following format: 12/34/56. I have found that react-input-mask allows to do so. But my question now is how to make the mask either require the user to fully enter the number (to remove such cases 1_/3_/_5) or add zeros where the number wasn't entered.
Also, another thing I think of is to allow either one or two digits, but I haven't seen documentation on this in react-input-mask
I am willing to choose another mask library, if you know it can be done so.
I figured it out. There is a property called maskChar, if you set it to null, e.g <InputMask maskChar={null} mask="99/99/99" /> won't allow user to proceed to second number, without filling both digits.
How to check a given napi_value of type napi_number is an integer or decimal (a number with fractional value) by using node.js native N-API function .
Look like there is no isInt() or isDouble() equivalent function in N-API (we don’t want to use V8 function call either). Let us consider a scenario where we are calling a native addon function f1() from JavaScript by passing a JavaScript object as argument as shown in the snippet.
let obj = { n1: 123, n2: 123.45 };
myaddon.f1( obj );
The native function f1() want to extract value associated with the keys n1 and n2 by calling the best fit value extraction N-API function. For example to extract value of n1 it may be best to use one of napi_get_value_int* and similarly for the n2 the double is a better choice.
napi_get_value_double
napi_get_value_int32
napi_get_value_uint32
napi_get_value_int64
Unfortunately I could not find any N-API function to verify the derivative of napi_number property. Have you come across similar situation, if so how did you solve this problem?
https://nodejs.org/api/n-api.html
A request has been opened with node-addon-api team regarding this feature and they provided an answer that sound logical. I thought of sharing the answer with this community that may help similar queries others may have. Here is the answer from node-addon-api team
While handling numbers with JavaScript, it is important to know
that all numbers in JavaScript are double-precision 64 bit IEEE
754 values (despite some engines like v8 might have additional
represents on small integers, there is no such definition in ECMA spec
and no way to determine these types of number in JavaScript).
napi_get_value_{double,int32,uint32,int64} just convert these value to
its desired one. There might be a precision loss in the conversion. If
a determined number is required in the case, use BigInt instead.
In the screenshot of the DOM you can see that the text ending in the numbers 623 is given a x value of 160. However, when I inspect the text, something something which is rendered before the numbers it has a length of 126.08px (see the second screenshot). This means that my text, which I translated 160px to the right, is not actually 160px to the right. From this article, I understand that unless a viewport is provided one user unit should equal one screen unit, but this is obviously not the case here. Why is this? Thanks! I'm using React if that is necessary.
You're setting "text-anchor' to "end' which will end up shifting the text to the left. Set it to 'start' (or possibly skip it altogether) and you should see the behavior you expect.
To get a consistent look and feel of both input and output views I am trying to use an disabled input element to display model data/values.
The value is a calculated temperature value and has several decimal digits. Since that does not make sense from an engineer's point of view I want to limit the displayed decimal digits to a certain amount (let's say two digits, the displayed value does not need to be rounded).
Example:
calculated value: 123.123456
value to display: 123.12
I read around the Internet and found many suggestions using input's step attribute like
step=".01"
to limit the decimal digits. There seem to be many people doing it that way, but it does not work for me.
I think view and data model need to kept separated so adapting the model data (like converting the values to strings or using toFixed()) does not seem to be a nice solution. The view should be able to format the data itself, not changing the data model and should have reading access in this case only.
There is a filter for doing this when accessing model data through the {{ }} notation. But this does not seem to be applicable straight out of the way.
So, do you have any suggestions about limiting the decimal numbers?
For the sake of investigation and in order to provide a working sample code I created a Pen.
I have a <input type="number"></input> field and when I try to put in a decimal as the first character, it comes up as invalid (I have an ng-change firing).
.5 won't work, but 0.5 is valid. Is there something I can do about this?
Per the HTML spec, .5 is valid for <input type="number">.
So, you’re right, and the tool (browser? Angular?) that validation error’s originating from is wrong.
As far as how to deal with it—how to work around it—I don’t know what to suggest, but as someone who actually works on the specs for this stuff, I would like to ask you to please at least file a bug against whatever tool is (mis)performing the actual validation that’s causing you to see that message. If nobody takes time to report spec-conformance bugs like this (but instead everybody works around it by just putting, e.g., 0.5 to get past it), then the bugs never get fixed.
Anyway as far as evidence for my assertion that .5 is in fact valid: The HTML spec is pretty clear on this; see the section defining what a valid floating-point number is:
A string is a valid floating-point number if it consists of:
Optionally, a U+002D HYPHEN-MINUS character (-).
One or both of the following, in the given order:
A series of one or more ASCII digits.
Both of the following, in the given order:
A single U+002E FULL STOP character (.).
A series of one or more ASCII digits.
Optionally:
Either a U+0065 LATIN SMALL LETTER E character (e) or a U+0045 LATIN CAPITAL LETTER E character (E).
Optionally, a U+002D HYPHEN-MINUS character (-) or U+002B PLUS SIGN character (+).
A series of one or more ASCII digits.
Along with that evidence from the spec itself, here’s a record of other supporting evidence: There was in fact a time when the HTML spec didn’t allow .5 but instead required it to be written as 0.5; however, after a “Floating point numbers beginning with a dot should be valid and parsed correctly” bug was raised against the spec, the spec was subsequently changed (in 2011) to state what it currently states (that is, too allow, e.g., .5).
So, any tool that’s flagging .5 as an error likely has not been updated in this regard since 2011, and so it regardless is in need of its maintainer(s) to go back into their code & evaluate their code against the current spec requirements, to make sure they are conforming to the current spec.
I hope the above provides enough ammunition to use in raising a bug against the responsible tool.
If you want all the input numbers to be valid then you can set in your input field step to "any". It works all integers and decimals numbers. Like -
<input type="number" step="any" />