The javascript date validator seems to be using "click" to decide when to
pop up. I notice when I tab into and out of the field the date widget is
not correctly dealt with. Most obnoxiously, it stays up when I tab out of
a field and continues to block form elements below the date field.
I'll look into the translations stuff to see how to change its locale. I
had not wanted to get into the T stuff as my site is strictly regional and
no translations are needed. /* Insert favorite joke about Americans and
their inability to speak other languages here! */ The colors and style are
also completely off for my site so maybe I can change those as well.
Anthony's idea about the widget is a brilliant one. I can make my own
widget class and avoid the automatic assignment of "date" to the input
class --
class DateWidget(StringWidget):
_class = 'date'
becomes:
class MyDateWidget(StringWidget):
_class = 'anything_but_date_here'
Reading thru the code I can see there is a lot of power in the widgets. I
can muck with "requires", "represents", etc. in addition to the input class.
Joe
On Sunday, August 25, 2013 4:47:36 AM UTC-7, Niphlod wrote:
>
> totally offtopic: that's why decimal was invented for ?!
>
> back in topic:
> if you don't need the js validators to kick in in any input because you
> want your own widget, strip them off the default code.
> if you need some custom widgets to match your own application logic
> (meaning "no, this one is not a "default" integer") than you are supposed
> to override the default widget for any Field that carries your own
> behaviour with your own widget. We can't include in web2py's code
> everyone's favourite play-tool, and that's why custom widgets are possible,
> and why there's the widget parameter in the Field class.
>
> As for the date(time) calendar, it's the only one ATM that can be:
> - used without licensing problems (anytime was briefely introduced and
> discarded for this reason)
> - localized without any issues just acting on the T translations.... (just
> change the translations for '%Y-%m-%d', '%Y-%m-%d %H:%M:%S' strings)
> - works for dates, times and datetimes all in one script
> - doesn't require any additional js library
>
>
> On Sunday, August 25, 2013 12:36:54 PM UTC+2, Joe Barnhart wrote:
>>
>> I'm well into the development of my commercial website and I find I am
>> running afoul of the built-in javascript validators in web2py more and more.
>>
>> If the validators were useless, the decision to just cut them out of the
>> code and be done with it would be easy and simple. But they do have their
>> usefulness, although in far less than 100% of the cases. Therein lies the
>> problem.
>>
>> In my application I'm treating amounts as an integer -- a fairly common
>> practice since real numbers do a poor job at representing exact amounts.
>> So all amounts are stored internally as pennies and I have a custom
>> validator that converts them to dollars and back for display. You can
>> already sense the problem coming... The field is, of course, an integer.
>> That triggers the automagic web2py javascript validator that prevents any
>> decimal numbers from being entered. ANYWHERE.
>>
>> Yes, I can fix it on my forms. I can change the class of the inputs
>> after they're built. Again and again. But suppose I need to make a quick
>> entry thru the appadmin interface? Bzzzzt! Thanks for playing -- you
>> can't enter cents at all in that interface because the automagic javascript
>> validator is in full force inside appadmin.
>>
>> Dates are another vexing issue. The calendar gadget is cute in small
>> doses, but it starts to wear thin when you realize we need to support
>> different locales, different color schemes, etc. So I guess we need to
>> implement the whole jQuery "theming" thing just to make the calendar match
>> the rest of the site. I still haven't found the best answer for default
>> "M-D-Y" entry instead of "Y-M-D".
>>
>> Maybe the Field constructor should have a different entry for the SQL
>> class of the field and its INPUT class. That way I could have a DB field
>> of "integer" and choose to call it "money" when it is built as an INPUT
>> control. At least it would make it easier to avoid the automagic
>> validation. The INPUT class could default to the SQL class for backwards
>> compatibility, but it would make it easier to start providing our own
>> validators and skipping the built in ones.
>>
>
--
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
