Hi there guys,

Just wondering how best to handle this...

I have some height and width fields to specify dimensions of products.

Requirements:

1. enforce 2 digits after the decimal point - auto insert (.)00 if a regular integer entered e.g a 1 becomes 1.00
2. The products should always have a height and width > 0 so 0.01 is the smallest value the user should be able to input
3. maximum of 6digits before the decimal point
4. If a user enters .1 it should transform value to 0.10
5. If a user enters .12 it should transform value to 0.12

Can the 'padding' of numbers be added into the validation like in 4 & 5 or should I just force them to be entered in this way?

Here's what I have so far:
Currently this allows 0.00 (not desirable) and 123456.78, 12.00 (desirable)

To illustrate further my requirements, these values should be allowed/disallowed:

Allowed	Disallowed
0.01	0.00
123456.99	012345.00
12.00	12.0
119.75	119.759
99.00	99

Any help with this would be massively appreciated!!!

many thanks in advance!

Gez

@g1smd

Sorry to trouble you but I wondered if you had any thoughts on this?

Thanks in adv.!

Gez

Why do you want to force 1.00 and 2.00 but not allow 0.00?

doesn't allow 10 or 20 or 205 or 250.
does allow .50 and .75 etc.

The {2,2} simplifies to {2} here.


Starting thoughts:
" 0 " OR " 1 to 9 + up to 5 digits + period + 2 digits "

Still thinking about the 0.01 to 0.99 part as that is missing.

The pattern can't "add" anything. It can merely test that the input conforms to a particular style.

Because a product's width or height will never be 0.00...

UPDATED: Here's the regex I have that seems to work as expected/desired:
Can this be more efficient in any way?

Many thanks,

Gez

doesn't allow 10 or 20 or 205 or 250.
does allow .50 and .75 etc.
doesn't allow 0 on it's own.

[0-9] simplifies to \d
{2,2} simplifies to {2}

Once you have "found" the 0 once there is no need to look for it again.
Once you have "found" the "period after the 0" once there is no need to look for it again.

Try:Design your pattern to parse left to right.



" 0 with optional .01 to .09 or .10 to .99 " OR " 1 to 9 + up to 5 digits + period + 2 digits "

The pattern can't "add" anything. It can merely test that the input conforms to a particular style.

g1smd wrote:
I missed that 0.01-0.99 was missing... I was just testing it and wasn't able to validate:
0.09
0.91

But
1.01
12345.95
612345.95
were valid.

Thanks! Gez

Is this too bloated?
UPDATED:As the previous expression wouldn't allow 101.dd OR 123400.dd because of the [1-9]

Thanks for the updates!!!

Will do L->R as you suggest. FYI everyone -Works perfectly Thanks to @g1smd!!!

K+1

Many thanks,

Gez

doesn't allow 0 on it's own.

[0-9] simplifies to \d
{2,2} simplifies to {2}

Once you have "found" the 0 once there is no need to look for it again.
Once you have "found" the "period after the 0" once there is no need to look for it again.

Try:Design your pattern to parse left to right.



" 0 with optional .01 to .09 or .10 to .99 " OR " 1 to 9 + up to 5 digits and period and 2 digits "

The pattern can't "add" anything. It can merely test that the input conforms to a particular style.

Huh?

However, I would be tempted to allow the user to miss off trailing decimal digits when they enter the numberand then have a separate routine that added .00 to the end of integers (except for 0) or added a 0 to the end of one-decimal-place numbers.

This saves a lot of time on data entry but with a consequent trade off in data accuracy.

If the wanted value is 2.09 and you insist on the user typing all digits, the data will be rejected if errors are made and 2.0 or 2.9 is entered with a digit missing; however nothing can be done is 250 is typed instead of 2050 etc.

If the input allows trailing digits to be omitted, then 2.09 miskeyed as 2.0 will be "corrected" to 2.00, and input miskeyed as 2.9 will be corrected to 2.90, introducing errors in the data.

This is a trade off you have to consider.

Will the user get annoyed if they have to type 10.00 over and over again, when typing just 10 would suffice? Or should you insist on all digits every time?

Remember, data entry format doesn't have to be the same as data display format.

@g1smd

All great points! I've given it a lot of consideration and in this instance, I want to enforce the adding of both decimals as the client will be working in cm.

However, after reading your post, I may actually split the input across 2 fields - 1 to capture the integer upto 6 digist long and the other to capture the 2digits past the point (default to 00 if none provided) and concatenate them with a decimal point. Then with a bit of jQuery, check that first is greater than 0, if not make sure the second input is in the (.)01 - (.)99 OTHERWISE transform the second into (.)00... You get my drift...

Anyway,

Thanks again!

Gez

Two fields might be less intuitive, the user will need to hit tab instead of point.

UI design is a complex field, not at all easy - and there's no 'one size fits all' solution.

I know what you mean. If I do it, they'll definitely be on the same line and the second will almost certainly be pre-filled with 00 that will be removed onFocus, re-inputted automatically if ="".

The other consideration for me is that although this client will be using cm, I will be making this dynamic through backend config to allow metres, cm, mm (all metric for the time being) so that it could work as an "Off the shelf" component. Therefore, if I go this route, I can dynamically code the second input to hide if the component has been configured to use mm as measurement.

*****ADD******
Users will also me able to mass import records from CSV to make the creation of products much simpler - given that most will already have their data in an excel file or some other format so, for the most part, I'd anticipate that they'd only be using this form to add the odd record and update existing ones.
*****************

Thanks again for everything!

Gez

No problem.