I don't think we need formal rules about teamwork in contrib, good sense is enough imho. Since the datepicker is meant to be widely used we must be careful though, I suggest we (Raluca, you, me for the moment) always attach a patch to the issue we wish to fix at least 24h before commiting, WDYT ?
Thanks, JV. On Fri, Apr 16, 2010 at 12:26 PM, Denis Gervalle <[email protected]> wrote: > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
