:-)
On Monday, August 12, 2013 1:35:43 PM UTC-4, Joe Barnhart wrote:
>
> 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.
