On Fri, Apr 9, 2010 at 10:07, Vincent Massol <[email protected]> wrote:
> > On Apr 9, 2010, at 9:45 AM, Jean-Vincent Drean wrote: > > > Hi, > > > > I'd like to use the date picker application [1] as a dependency in one > > of my project. > > It has already been 'released' and AFAIK it is successfully used in > > production, I'd like to commit it to > > contrib/projects/xwiki-application-datepicker and perform a maven > > release (1.0) from the current code. > > > > Here's my +1. > > > > [1] > http://code.xwiki.org/xwiki/bin/view/Applications/DatePickerApplication > > +1 but I also think we should fold it in the platform as a default editor > for XObject date fields (this one or another, I don't know how well it's > coded). > I am not sure the code is really nice, but this date picker has many good features, so this is not a bad choice. However, there are many possible arguments to that date picker and it depends what you expect from it, but the basis are not good enough IMO. Here are some of the issues: - The box is not placed properly just under the field, but at a constant distance of 30 px. Depending on browser this put the box well or not. You may set the topOffset to another value, but it is relative to the top of the field, which is not pratical. - When you click the input field, with the intend to manually encode a date, the calendar open, and you have to close it since... - By default, the calendar does not close when you leave the date field. Since it is placed at the end of the body, this break normal tabbing. - The CloseOnBlur which is aimed to solve previous issues, has a serious problem. Since the calendar itself could receive the focus, it close when you click to change months. The delay before closing is also too long, which is confusing. - You may use an external image to trigger the calendar, which is IMO less invasive and clearer, but this does not remove the triggering by the input field and defeat the purpose. - It does not work in a lightbox We had make many improvement to be able to use it on production sites in a form context. There is no perfect solution, and some my choice are arbitrary and could probably be improved, but my fixes ensure: - that the focus stay on the field while the calendar is in use, and you cannot leave the field while over the calendar. - closing on blur is done properly, and if not used, leaving the field require to close the calendar first, preventing many calendars open simultaneously. - it works in lightbox - a image is attached to the extension for a default image for external trigger - when external trigger is used, the input field does not trigger the calendar You may compare original code and our improvement from the following URL: Original: http://sandbox.xwikidev.softec.lu/site/DatePickerTest/ Improved: http://sandbox.xwiki.softec.lu/site/DatePickerTest/ Date field is an example with external trigger and close on blur Date2 field is an example with input trigge and close on blur Date3 field is an example without close on blur With our improvements, I would like to see this automatically used on date fields with . My preference would be to use it with an external control, to be not so invasive. You have my +0 for the original code into contrib. WDYT? Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
