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.
