On Fri, Apr 9, 2010 at 10:07, Vincent Massol <vincent(a)massol.net> 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