Validator inRange rule should have an inclusive/exclusive option about lithium HOT 8 CLOSED

So the inRange validator with options lower set to 5 and upper to 10 in exclusive mode should match 3 and 11 but not 7?

from lithium.

No.

inRange with lower => 5 and upper => 10 in exclusive mode should match
between 6 and 9
inRange with lower => 5 and upper => 10 in inclusive(exclusive=>false)
mode should match between 5 and 10

I think what You thinking about is notInRange validator.

On 09/05/2011 03:36 AM, davidpersson wrote:

So the inRange validator with options lower set to 5 and upper to 10 in exclusive mode should match 3 and 11 but not 7?

from lithium.

Thanks for your explanation. I don't see a why you can't achieve this by specifying lower 6 and upper 9 when it does what you want. Seems clearer to me, wouldn't require reading about/documenting an additional feature and is more straightforward. I'm closing this for now, anybody who has a stronger feeling about implementing this can reopen the ticket.

from lithium.

How can I validate integers (without decimal digits) with the default
validators?

I think it makes sense when using floats.
I can't validate floats with 'decimal', only fixed point numbers.
If I want to validate float between 2.71 and 3.14 inclusively I would
probably use the following validators:
'decimal' without precision option, this will validate that the
value is really a float number
'inRange' with lower 2.71 and upper 3.14
currently it won't match the limits
as You said I can extend a range to 2.70 and 3.15 but it still
matches 2.701 or 2.7000345 or 3.1486578563

Do You see my problem?

On 09/05/2011 03:00 PM, davidpersson wrote:

Thanks for your explanation. I don't see a why you can't achieve this by specifying lower 6 and upper 9 when it does what you want. Seems clearer to me, wouldn't require reading about/documenting an additional feature and is more straightforward. I'm closing this for now, anybody who has a stronger feeling about implementing this can reopen the ticket.

from lithium.

Couldn't the issue @threestan is seeing be resolved by instead switching the isRange validator to be inclusive all the time?

from lithium.

@threestan I don't think this is common enough to warrant patching the core. What's wrong with just adding a custom validation rule in your app?

from lithium.

Sure, I did so.
IMHO inclusive is the expected behavior

from lithium.

Finally getting caught up here. @threestan I'm fine with inclusive being the default behavior here. If you're willing to provide a patch and a test case in a PR against the dev branch, we'll get it into core.

from lithium.