Also:
Field('birthday', 'date',
widget=lambda f, v: SQLFORM.widgets.date.widget(f, v, _class=
'string')
Anthony
On Monday, August 12, 2013 4:19:20 AM UTC-4, Joe Barnhart wrote:
>
> That's a great find, Massimo, but reading it thru it seems the order can't
> be mucked with programmatically.
>
> Since this is a form with a custom formstyle, I put in a snipped to set my
> 'date' classes back to 'string' in the formstyle. It's a workaround, but
> I'm not looking for purity here, just functionality, and this approach
> worked.
>
> That whole "formstyle" thing is a very neat hook. It greatly extends the
> built-in SQLFORM functionality.
>
> -- Joe
>
> On Monday, August 12, 2013 12:19:33 AM UTC-7, Massimo Di Pierro wrote:
>>
>> Perhaps this helps:
>>
>> http://stackoverflow.com/questions/3934570/order-of-execution-of-jquery-document-ready
>>
>> Looks like it should be possible to alter the order in which registered
>> onload callbacks are executed. You want to remove "date" class before the
>> web2py.js datepicker is called.
>>
>> On Monday, 12 August 2013 07:29:20 UTC+2, Joe Barnhart wrote:
>>>
>>> So I have this one field. It's a date -- a birthday in fact. It's
>>> definitely a date, and yet, I do NOT want the extra help of the datepicker
>>> on this PARTICULAR date. Oh, it's fine for those OTHER dates in my forms,
>>> just not THIS date.
>>>
>>> Boldly I set off to unhook my particular birth date field from the
>>> automagic datepicker gadget. THe first thing I tried is to remove the
>>> "date" class from this particular input field. I used the old jQuery
>>> $(document).load() and tossed its date class. Problem solved? NO! That
>>> darned datepicker is worse that Jason from the original Friday the 13th
>>> movie. Now it has decided that it doesn't need the "date" class before it
>>> seizes a field. Or, rather, the datepicker has already attached itself
>>> like a parasite and my removal of the "date" class has no effect.
>>>
>>> Do I need to change layout.html to put the web2py datepicker stuff in a
>>> place where it loads AFTER my panel? I've already loaded my stuff in the
>>> {{block head}} to get it loaded as early as possible, and the rest of the
>>> javascript is loaded at the end of the document. But I guess that's not
>>> good enough. I could start "unbind"ing things until my datepicker problem
>>> goes away, but there's TONS of things binding to all sorts of events, and I
>>> don't want to screw up any more than I have to...
>>>
>>> In a longer-term sense, is there any way to make this whole
>>> datepicker/timepicker thing more "optional"? This is not my first run-in
>>> with this feature. I know many people like the "convenience" of this
>>> feature but to me it's always been a mixed bag. Especially the "all or
>>> nothing" approach we now have where you either take it on all of your
>>> fields or kill it for the site by not loading the js.
>>>
>>> -- Joe
>>>
>>
--
---
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.
