Yes, I could ! What is the rules on contrib ?
doesn't these improvements
require a vote ? We should also look at style improvement proposed recently.
Denis
On Fri, Apr 16, 2010 at 10:52, Jean-Vincent Drean <jean-vincent(a)drean.org>wrote;wrote:
Nice improvements, they definitely need to be
applied.
Do you plan on commiting them now that the app is on contrib ?
Thanks,
JV.
On Mon, Apr 12, 2010 at 10:31 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
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?
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org