Wow, you are awesome Anthony! You come up with the best one-liners!
-- Joe
On Monday, August 12, 2013 6:12:04 AM UTC-7, Anthony wrote:
>
> 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.
