[Building Sakai] Sakai DateTime Picker

Matthew Jones matthew at longsight.com
Mon Jul 28 21:14:51 PDT 2014


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/cabd3c9c/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/cabd3c9c/attachment.png 


More information about the sakai-dev mailing list