[xwiki-devs] [VOTE] Add the DatePicker application to the contrib repository
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 Thanks, JV.
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). Thanks -Vincent
On Fri, Apr 9, 2010 at 10:07, Vincent Massol <vincent@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
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@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?
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@drean.org>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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
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 <dgl@softec.lu> 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 <jean-vincent@drean.org>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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
+0 On Fri, Apr 9, 2010 at 09:45, Jean-Vincent Drean <jean-vincent@drean.org> 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
Thanks, JV. _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+0 Thanks, Marius 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
Thanks, JV. _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Two +1, two +0. Done. ps: +1 with Vincent, we shoud provide date pickers for date props in the platform. Thanks, JV. On Fri, Apr 9, 2010 at 9:45 AM, Jean-Vincent Drean <jean-vincent@drean.org> 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
Thanks, JV.
participants (5)
-
Denis Gervalle -
Jean-Vincent Drean -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol