Item8677: Change JSCalendarContrib (used for instance for date fields in an EditTable) to display time selector if formatting parameters contains time

JSCalendarContrib does not display times, despite the fact that it is able to do it.

pub/System/JSCalendarContrib/foswiki.js hardcodes and forces cal.showsTime=false 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 :

1. you don't get a time selector
2. 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.

The javascript should be changed to enable "showsTime" when the date format passed includes hours, or hours and minutes, and otherwise keep it as "false" and display only a calendar with dates selection. That's all that needs to be changed! And it produces this:

• 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 for instance: 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.

Also, I will look at whether the javascript UI for the time selection can be improved a bit, to make entering a time easier. If it looks too complicated I will just drop it, since I understand that in the next major release Foswiki will use a JQuery based calendar with date and time pickers. (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.

-- RaulFRodriguez - 06 Mar 2010

Hi Raul,

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!

-- PaulHarvey - 07 Mar 2010

Thanks Paul.

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.

-- RaulFRodriguez - 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 the second part I will look at whether the javascript UI for the time selection can be improved a bit, to make entering a time easier. - 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.

-- CrawfordCurrie - 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.

-- RaulFRodriguez - 12 Mar 2010

Set to minor/1.1

-- PaulHarvey - 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 ... the %$SHORTDESCRIPTION%, %$POD% 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?

-- RaulFRodriguez - 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 in Tasks.Item2111. This warning appears to relate to the discussion about Tasks.Item8235 (and Support.Question252). There is a check-in by CrawfordCurrie in Tasks.Item8235 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

-- RaulFRodriguez - 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.

-- KennethLavrsen - 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.

-- RaulFRodriguez - 02 Apr 2010

foswiki.js is a derived object, built by BuildContrib, and should not be checked in.

-- CrawfordCurrie - 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 twiki.js in distro:9558530bbabd on... 19 November 2008 before it was renamed as foswiki.js 7 days after by ArthurClemens in distro:dac205e16045

Provided foswiki.js will be built when the release is done (from the foswiki_src.js 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 %$SHORTDESCRIPTION%, %$POD% 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".

-- RaulFRodriguez - 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.

-- RaulFRodriguez - 05 Jun 2010

Commenting is disabled while not logged in