Item8677: Change JSCalendarContrib (used for instance for date fields in an EditTable) to display time selector if formatting parameters contains time
does not display times, despite the fact that it is able to do it.
hardcodes and forces
even though the time format passed to the Contrib may contain hours and minutes, which is wrong.
The result is that the calendar does not display the time fields despite the fact that, according to the documentation of JSCalendarContrib
you can pass a format string such as:
%e %B %Y - %H:%M
If you do that in Foswiki, there are two problems :
- you don't get a time selector
- after you click on a date, the date and time according to the format you entered is displayed, i.e.: a time you haven't been able to define yourself, because the calendar was not allowing it
I believe that deactivation of the display of the time selection, by forcing always only dates is a bug, since date and time format specification are still allowed in the JSCalendarContrib
, and what the user gets is an arbitrary time instead of a time he can select.
I suggest the following change to the behaviour of JSCalendarContrib
, which, hopefully should not interfere with current uses.
- Calendar in action, able to display a time selector when it uses the showsTime=true setting:
That would allow the time selection functionality when the user actually asks for it by crafting its date format
date, 15, , %e %B %Y - %H:%M
in an %EDITTABLE%. You would be allowed to obtain the date and time information in a single column
If no time markers are specified, the calendar would stay displayed as normal (without a time selector).
I am working on this at the moment for my own Foswiki installations.
(withdrawn -- RaulFRodriguez
- 12 Mar 2010)
This behaviour should be properly documented also.
I am putting Crawford in the WaitingFor to have his views on this, as he is mentioned as the author of this Contrib.
I am not filing this as an improvement suggestion, since I believe that's a bug, but of course, feel free to comment and tell me I am wrong
In fact, solving this bug would indeed be a Foswiki improvement for me... so if you believe this should be submitted to the community review using the 14 days rule, I will do that.
Otherwise, I would check-in these changes to SVN.
- 06 Mar 2010
I have noticed this weakness too, but never got around to doing anything about it. I hope Crawford will agree that there's no need to go through the feature process.
Eventually it would be nice to switch to something like http://jqueryui.com/demos/datepicker/
Looking forward to seeing this check-in!
- 07 Mar 2010
As per Kenneth's today's recommendation on the list, I will submit this to a community review, and will create a "Feature Proposal" for this issue. In the meantime, I have changed the status from "Being worked on" to "Closed" and will re-open it, or create a new item depending on the result of the consultation.
- 08 Mar 2010
This task is in two parts. Reading the description above, I am also inclined to regard the first part as a bug. There should be no compatibility issues with the fix if the time is only shown when a time selector is present in the format string, as described. So I'd say, just fix it. A feature proposal would be overkill.
However I am excluding
- that does
need a feature proposal, and I suggest you drop it from this task.
BTW a task should not be put into "closed" state unless there is at least one checkin. If nothing needs doing, then select "No action required". In this case, the task should remain open, for re-use if you decide to go through the feature process, or for fixing if you decide not to bother.
- 09 Mar 2010
Crawford, since Kenneth requested it, I feel obligated to open that Feature Proposal. I am suggesting to him that it could be checked-in as a "no-brainer" one, subject to the result of the Feature Proposal.
I confirm that I withdraw the "second part" as you quote it.
- 12 Mar 2010
Set to minor/1.1
- 13 Mar 2010
Given that the Feature Proposal Development.AllowJSCalendarContribToUseTimePicker
was adopted, I have committed to Trunk the changes described in this task as specified in the Feature Proposal.
The changes seem to work well on Trunk: http://trunk.foswiki.org/Sandbox/TestJSCalendarContrib
But documentation page looks weird on http://trunk.foswiki.org/System/JSCalendarContrib
variables do not get expanded. Did I miss something?
Also, there is a strange notice in the Change History that says "Warning: Do not merge trunk version of this contrib to release branch. It is currently not compatible.".
Did you add it Crawford? Why is this there? If I apply the patches to the Release branch, is it likely to cause any problem?
- 01 Apr 2010
So, I've been doing some research...
The notice in the Change History that says "Warning: Do not merge trunk version of this contrib to release branch. It is currently not compatible." was added by KennethLavrsen
. This warning appears to relate to the discussion about Tasks.Item8235
). There is a check-in by CrawfordCurrie
and the status is "Waiting for Release". I understand that the Trunk version has (had ?) a problem. I am unsure if this has been completely solved (at least, the warning is still there).
If my understanding of the various comments I read is correct, the Release branch was not affected by the existing problem in Trunk. So my guess is that I can apply the changes I made. I will do so from scratch in the Release branch using my SVN Release checkout, and not pushing the changed files from Trunk.
And I will let the Warning notice stay where it is in Trunk
- 01 Apr 2010
It is not that the version in trunk is broken. But it is not compatible with Foswiki 1.0.X. There was a change done in the API that the contrib uses so trunk version of JSCal... only works with trunk.
So the message is - do not release a JSCalendarContrib
from trunk to foswiki.org because it fails when people install it on 1.0.X.
Always release the default extensions from the current release branch - never from trunk. This is the general message for all the default (distributed with Foswiki) extensions.
- 02 Apr 2010
OK, thanks Kenneth for clarifying this. I added the changes to Trunk (Rev 7019 not found distro:856bba540aaf distro:e47121d555e4 distro:fe59b2136c57 distro:5f2cda229c02
) and Release (distro:a485623ff30d
), and I did so separately.
The functionality for displaying the time-picker is now checked-in and documented in both the versions of JSCalendarContrib
preserving the way each version is supposed to work.
- 02 Apr 2010
foswiki.js is a derived object, built by BuildContrib
, and should not be checked in.
- 03 Apr 2010
Thanks Crawford. I see you removed the file from the repository.
Of course, I did not checked it in, in the first place... In fact, you were the one that added it as
on... 19 November 2008 before it was renamed as
7 days after by ArthurClemens
will be built when the release is done (from the
I patched too), I don't have any problem. You are the master of your Contrib
I understand that this will be done when building the release by Kenneth or the person building it, and I don't need to do anything (I am not required to use BuildContrib
myself at this stage). I understand also that the
variables will get expanded properly in the documentation at that time too.
So, my work on this item is finished for me, and I set the status to "Waiting for release".
- 12 Apr 2010
Changed the Priority field to "Enhancement" so that it appears in the correct category, since it was decided to treat this as a Feature Proposal, and changed the summary of the Task to describe an added feature, instead of describing a bug.
- 05 Jun 2010