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 <jlund...@pobox.com> wrote: > 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 the former. > > It might be appropriate to provide aliases for filter-only validators along > the lines of TO_UPPER(), change the docs, and deprecate IS_UPPER() on the > grounds of ambiguity. But I don't see a motivation for changing the semantics > of IS_UPPER(), since there's no real benefit to be had, and it would break a > lot of existing code. > > Notice that some validators do both. That is, they validate their input, and > also transform it. This is one of those cases where it's advisable for a > developer to read the docs. > > > > > +-[ Gergely Kontra <pihent...@gmail.com> ]------------------+ > > | | > > | Mobile:(+36 20)356 9656 | > > | | > > +- "Olyan lángész vagyok, hogy poroltóval kellene járnom!" -+ > > > On Mon, Feb 8, 2010 at 04:17, Jonathan Lundell <jlund...@pobox.com> wrote: > >> 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.... > > >>> On Feb 7, 8:22 pm, Iceberg <iceb...@21cn.com> 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 a single line. :) > > >>>> Well, sounds like I support changing IS_UPPER() 's behavior. But > >>>> actually I am neutral to this proposal. > > >>>> On Feb7, 3:24pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > > >>>>> 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. > > >>>>> -Thadeus > > >>>>> On Sat, Feb 6, 2010 at 11:33 PM, Iceberg <iceb...@21cn.com> wrote: > >>>>>> @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 > >>>>>> perhaps another UPPERCASE() to uppercase. As long as the old apps do > >>>>>> not really break, but just sightly change its behavior in acceptable > >>>>>> range, I consider web2py is still backward compatible. > > >>>>>> About web3py, Renato says all. :) > > >>>>>> On Feb6, 8:24pm, Renato-ES-Brazil <renatoa...@gmail.com> wrote: > >>>>>>> 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-backward compatible changes. > >>>>>>>> 2010-2011 are reasonable dates but just a guess. > > >>>>>>> URL:http://www.mail-archive.com/web2py@googlegroups.com/msg09344.html > > >>>>>>> On 6 fev, 08:12, pihentagy <pihent...@gmail.com> wrote: > > >>>>>>>> Hi! > > >>>>>>>> Looking into the code of IS_UPPER I realized, that this function does > >>>>>>>> not do, what I expect to do. > >>>>>>>> I thought it only allows strings, which does not have lowercase > >>>>>>>> letters, but it actually converts the string to uppercase. > > >>>>>>>> Since web2py promises backwards compatibility, and here IMHO this > >>>>>>>> method is mis-named, how would you solve the situation? > > >>>>>>>> BTW when I come across the fact, that web2py will be always backwards > >>>>>>>> compatible, a loud alarm began to horn in my head: then how would you > >>>>>>>> maintain the code in 2, 3, 10 years? It will blow up. > > >>>>>>>> Or, when it becomes hard to maintain, you began a new project named > >>>>>>>> web3py? :) > > >>>>>>>> Gergo > > -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
