[Building Sakai] Sakai DateTime Picker
Cris J Holdorph
holdorph at unicon.net
Tue Jul 29 08:56:04 PDT 2014
I know the datepicker does the i18n month names correctly. My comments
were in regards to if you stared letting the user enter data in the text
field WITHOUT using the datepicker.
---- Cris J H
On 07/29/2014 08:50 AM, Bryan Holladay wrote:
> Matt's change is perfect and doesn't open the pandora's box for user
> input parsing. As for i18n, the calendar tool already has regional
> calendar settings, so the month names are already correct. For example:
>
> $.datepicker.regional['af'] = {
>
> closeText: 'Selekteer',
>
> prevText: 'Vorige',
>
> nextText: 'Volgende',
>
> currentText: 'Vandag',
>
> monthNames:
> ['Januarie','Februarie','Maart','April','Mei','Junie',
>
>
> 'Julie','Augustus','September','Oktober','November','Desember'],
>
> monthNamesShort: ['Jan', 'Feb', 'Mrt', 'Apr', 'Mei', 'Jun',
>
> 'Jul', 'Aug', 'Sep', 'Okt', 'Nov', 'Des'],
>
>
>
> On Tue, Jul 29, 2014 at 10:34 AM, Cris J Holdorph <holdorph at unicon.net
> <mailto:holdorph at unicon.net>> wrote:
>
> 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>
> > <mailto: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>
> <mailto: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>
> <mailto: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>
> > <mailto: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>
> > <mailto: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
> <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
> <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"
>
>
More information about the sakai-dev
mailing list