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 <[email protected]>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 <[email protected]> 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
