[Building Sakai] Sakai DateTime Picker

Bryan Holladay holladay at longsight.com
Tue Jul 29 05:23:03 PDT 2014


I think adding the dropdown options in the datepicker would be just fine...
any objections?  Should this be a default option or just for the
assignments tool (my vote is default)?

-Bryan


On Tue, Jul 29, 2014 at 12:14 AM, Matthew Jones <matthew at longsight.com>
wrote:

> Portal already uses mobile esp (via mobile detect library) and puts a few
> variables into the context (mobileDevice and mobileSmallDisplay). So
> detecting whether or not it's mobile I don't see as a problem.
>
> I'd consider the bigger problem that without the popup date time picker
> what format are people going to put the dates in. It can't possibly support
> parsing every possible date time format in the backend and the popup helps
> restrict and guide what people input.
>
> Though you mention that it works but the only inconvenience is changing
> the year, it looks like there's options for that in the existing date
> picker that just aren't enabled and are easy to switch on. Sounds like a
> good default to me.
> http://jqueryui.com/datepicker/#dropdown-month-year
>
>
>> And there are also better looking date pickers for mobile in the jquery
> mobile project. Having them all consolidated into one makes it easier to
> detect and switch. (if interest and dev time were available)
>
> A few jQuery Mobile specific date pickers here:
> http://dev.jtsage.com/jQM-DateBox/
>
>
>
> On Mon, Jul 28, 2014 at 9:33 PM, Bryan Holladay <holladay at longsight.com>
> wrote:
>
>> I had an instructor come up to me today and ask why she couldn't just
>> type in the dates when changing the open/close dates in her newly imported
>> assignments (it was annoying to her to have to click "next month" 12 times
>> instead of just updating the year).  I wasn't expecting the datetime picker
>> to work this way, but it does and does so apparently for mobile devices.  I
>> understand why you wouldn't want to show the keyboard on a mobile device,
>> but I don't know why you'd want to disable keyboard inputs for non mobile
>> computers.  Is there a simple way for the JS file to know whether the
>> device is mobile or not already inside Sakai's JS API?  The SO solution is
>> just a long REGEX check:
>> http://stackoverflow.com/questions/11381673/javascript-solution-to-detect-mobile-browser.
>>  I think we should not have the input disabled by default unless proven to
>> be a mobile device.  Thoughts?
>>
>> Here is the datetime picker JS code:
>>
>>
>> https://source.sakaiproject.org/svn/reference/trunk/library/src/webapp/js/lang-datepicker/lang-datepicker.js
>>
>> // disable the input field on show as to not display a tablet keyboard
>>
>>  cfg.onClose = function(dateText, inst) {
>>
>>  $(this).removeProp("disabled");
>>
>>  };
>>
>>  // re-enables input field
>>
>>  cfg.beforeShow = function(input, inst) {
>>
>>  $(this).prop("disabled", 'disabled');
>>
>>  };
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140729/04cfafc5/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: calendar drop.png
Type: image/png
Size: 18634 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140729/04cfafc5/attachment.png 


More information about the sakai-dev mailing list