Mind that all validators are filters in one way or another. The
representation of the input data is not alwasy tha same as the
representation of the data that goes in db. date is an example.
On Feb 8, 10:10 am, Jonathan Lundell wrote:
> On Feb 8, 2010, at 12:59 AM, KONTRA, Gergely wrote:
>
> > Hi
On Feb 8, 2010, at 12:59 AM, KONTRA, Gergely wrote:
> Hi!
>
> Yes, I must admit it, that a validator like IS_UPPER(), which checks
> only whether the input is uppercase is less useful, than an another,
> which actually converts to uppercase.
>
> OTOH if you haven't used the function, you expect
Hi!
Yes, I must admit it, that a validator like IS_UPPER(), which checks
only whether the input is uppercase is less useful, than an another,
which actually converts to uppercase.
OTOH if you haven't used the function, you expect the former.
+-[ Gergely Kontra ]--+
|
On Feb 7, 2010, at 6:32 PM, mdipierro wrote:
> We could add an option like "strict=False" that if true does what you
> ask.
What's the use case? I'm having trouble seeing what such an option would do for
you.
Sure, IS_UPPER() should probably have been named TO_UPPER(). But at this
point
>
No, you cannot rely on the user. Users are stupid. The system needs to
be as simple as possible for the users to use the system to get their
work done. There is no need to bother the user with "Form errors:
Value must be uppercase". This wastes the users time to have to
remember to input in upper c
We could add an option like "strict=False" that if true does what you
ask.
On Feb 7, 8:22 pm, Iceberg wrote:
> But in this case (provided that we really change IS_UPPER() as
> Pihentagy suggested), you can rely on the human, because they can not
> input lower case. Your app still need not to edit
But in this case (provided that we really change IS_UPPER() as
Pihentagy suggested), you can rely on the human, because they can not
input lower case. Your app still need not to edit a single line. :)
Well, sounds like I support changing IS_UPPER() 's behavior. But
actually I am neutral to this pr
It will break backwards compatibility.
I have apps that rely on the functionality of IS_UPPER applying
.upper() to the incoming variables. Anything that requires me to edit
a single line of code on my app to just upgrade web2py breaks
backwards compatibility, unless it was a bug to begin with.
-T
@Pihentagy:
Besides, the current IS_UPPER() (and IS_LOWER()) is not that bad,
IMHO. What is the real difference between alarm end user to change his
input into upper case, or just silently change his input into upper
case?
To say the least, we can really change IS_UPPER() to just warning, and
per
Web3py is an alternative, check this:
> When GAE moves to 3.0 and the database drivers for all supported
> backends become available we will release something like web3py (TM).
> Since we are going to break language backward compatibility that will
> also be a good time to include other non-backwa
10 matches
Mail list logo
