[Building Sakai] Sakai DateTime Picker

[Cris J Holdorph]

I think the fix by Matt works for the original problem Bryan was describing.

I did want to add to this thread though, for anyone looking at it in the 
future.

Please be aware of I18n issues when doing stuff with the date fields. 
One of the reasons text input is disabled in so many of the text fields, 
is that the back end code is not set up to do very good error 
handling/text parsing.  So preventing bad input in the first place is 
easier.

I mention the I18n issues, because doing more robust back-end validation 
on the input gets a lot more complex if you are trying to handle i18n 
input.  I'm not saying it's impossible, but the effort required to do it 
in an i18n compatible way *AND* provide the user with good feedback, is 
higher then most people would think.

---- Cris J H

On 07/29/2014 07:10 AM, Matthew Jones wrote:
> I have filed and fixed this as the default for 11, since I don't see any
> disadvantages. I'd consider it worthwhile for 10. I don't think just
> assignment would benefit.
>
> https://jira.sakaiproject.org/browse/SAK-27733
>
>
> On Tue, Jul 29, 2014 at 8:23 AM, Bryan Holladay <holladay at longsight.com
> <mailto:holladay at longsight.com>> wrote:
>
>     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 <mailto: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 <mailto: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
>             <mailto: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
>             <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with
>             a subject of "unsubscribe"
>
>
>
>
>
>
> _______________________________________________
> 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"
>