create new tag
, view all tags
Note: JSCalendar is already shipped as a contrib JSCalendarContrib

We use a lot of dates in our intranet, so we depend on correct date formats in formfields. To ensure this I extended the existing types by a date-type and combined it with a datepicker.

I chose the calendar widget from Mihai Bazon http://dynarch.com/mishoo/calendar.epl which is released under GNU LGPL and written in javascript.

Installation instruction

Install JS Calendar

  1. Go to http://dynarch.com/mishoo/calendar.epl and download the actual calendar zip.
  2. Unzip it in an appropriate location: twiki/pub/TWiki/JsCalendar.
  3. Ensure the permissions are set right!


To include the calendar script apply the following lines within the head section of your edit.tmpl file:

  <link rel="stylesheet" type="text/css" media="all" href="%PUBURL%/TWiki/JsCalendar/calendar-win2k-cold-1.css" title="win2k-cold-1" />
  <script type="text/javascript" src="%PUBURL%/TWiki/JsCalendar/calendar.js"></script>
  <script type="text/javascript" src="%PUBURL%/TWiki/JsCalendar/lang/calendar-en.js"></script>
  <script type="text/javascript" src="%PUBURL%/TWiki/JsCalendar/calendar-setup.js"></script>


if( $type eq "text" ) {
            $value =~ s/"/"/go; # Make sure double quote don't kill us
            $value =~ s/&/&amp\;/go;
            $value =~ s/</&lt\;/go;
            $value =~ s/>/&gt\;/go;
            $value = "<input type=\"text\" name=\"$name\" size=\"$size\" value=\"$value\" />";

insert a the new date-type:

elsif ( $type eq "date" ) {
            $value =~ s/"/"/go; # Make sure double quote don't kill us
            $value =~ s/&/&amp\;/go;
            $value =~ s/</&lt\;/go;
            $value =~ s/>/&gt\;/go;
            $value = "<input type=\"text\" name=\"$name\" id=\"id$name\"size=\"$size\" value=\"$value\" />
                      <button type=\"reset\" id=\"trigger$name\">...</button>
                 <script type=\"text/javascript\">
                        inputField     :    \"id$name\",      // id of the input field
                        ifFormat       :    \"dd M y\",       // format of the input field
                        button         :    \"trigger$name\",   // trigger for the calendar (button ID)
                        singleClick    :    true            // double-click mode

Test the installation

After these steps, make a Form-Topic which use the date-type see screenshot:


Have fun! smile


  • The window is place right under the formfield, so you have to order the date-fields rather on top of the form.
  • Additionally you can set the inputfield readonly to prevent manual editing

-- AndreUlrich - 12 Oct 2003


This looks cute and is useful for Intranet use!

The web site states that the date picker is DHTML, e.g. it does raise the bar on required browser. This is/is not a issue, depending on the company.

This could be packaged as a Plugin. JohnTalintyre added a hook which might offer what you need, see ExtendingFormControls.

-- PeterThoeny - 12 Oct 2003

Just a word to say: great !!!

-- ColasNahaboo - 12 Oct 2003

Excellent stuff, I'd love to include this in FormFieldsPlugin. Although it could just go in its own plugin now that the Plugin API allows extra control to be added to forms.

-- JohnTalintyre - 12 Oct 2003

I am in the process of integrating this into core. I will upload a patch here for people to try before committing. I will:

  • Make it part of the core, not a Plugin, because of documentation issues. Having the definitions of differents fields in separate docs is not something desirable.
    • Can you please further explain the documentation issues? -MC
  • Thus, I will use a dir %PUBDIR%/_jscalendar to store the calendar script files, not attachements to a topic.
    • See below -MC
  • I have added this functionality to both the core (Forms) and the EditTablePlugin.
  • implementation is in Forms.pm & EditTablePlugin.pm, which issue some <input> code and set a perl field of $query, $query->{'jscalendar'} = 1; The scripts bin/view and bin/edit checks this value at the end, and insert the needed header code before the current </head>= tag in memory. This way, nothing has to be done in the skin, and nothing is downloaded if the TWiki page do not actually use a "date" field. No performance overhead!
  • This header code is fetched in a template/jscalendar.tmpl template, allowing skins to decorate the calendar as they see fit
  • Another template is used, template/jscalendaroptions.tmpl, that will be used to add to the Calendar.setup options, (comma-prefixed) such as , mondayFirst : true

-- ColasNahaboo - 15 Oct 2003

Ok, uploaded JsCalendar.zip: patch to Beijing, v1

To install:

  • uncompress in your wiki dir
  • apply the patch to edit, view, Form.pm
    patch < JsCalendar.patch
    rm JsCalendar.patch
  • if needed, create and add options to template/jscalendaroptions.tmpl such as: (the first comma is important)
    , mondayFirst : true
  • if you use the EditTablePlugin, you will want to install the 15 Oct 2003 version

-- ColasNahaboo - 15 Oct 2003

I think we ought to be wary about making adhoc directories in pub - I suggest we declare a common top level directory (e.g. _JavaScriptComponents) and then have a naming scheme and a method to allocate space in the resulting directory.

This would leave us with:

  • /pub/_JavaScriptComponents/JsCalendar/CalendarPicker.js, etc.
  • /pub/_JavaScriptComponents/IEJS/IEJS.editbar.js, etc

In fact, whilst I appreciate the caution about having JavaScript (or any code) components changeable through the web, I would urge the use of (and possible tightening of) the security mechanisms such that we can make a TWikiJSComponents web for them.

We'd then treat the installation of these components as mere installations of topics.

IMO, templates need thought to separate issues. I was hoping (but failed) to catch you on TWikiIRC before writing here - so maybe later.

-- MartinCleaver - 15 Oct 2003

  • common top level directory: good point. what about _javascript to keep the convention of all-lowercase for non-web pub dirs
  • I am against having distributed parts of TWiki in webs, because that means you can edit them locally... and then you cannot upgrade easily anymore (unzipping a distrib will clobber your local changes). This does not means that local customizations cannot be in TWiki topics, only that we should not distribute TWiki topics
I was in a hurry to install this properly at work (users asking me for this every hour smile Now we can take some time to look at things. I think that:
  • template/jscalendar.tmpl should stay a template. It deals with style, it should be with other templates.
  • template/jscalendaroptions.tmpl could be in Webs however. It can very well be a WebPreferences variable, for instance. Note that I didnt include this file in the distrib, as it is to be edited locally, it should not be part of the distrib!

-- ColasNahaboo - 15 Oct 2003

I'm not so sure about this going into the core, just saying it's a documentation issue isn't really enough reason and certainly invalidates recent changes to the plugin API to allow extensions like this. Plugin API allow for extensions of this type, why not go this route first? That way it's easier for other people to produce variants of this and we don't find demand to put lot of different JavaScript based edit components into the core.

I would think there's a stronger case for part of FormFieldsPlugin to go into the core as one of the controls is designed for preference editing. Why not go plugin for now and if there are real problem put into core. We could always have this as a standard plugin.

-- JohnTalintyre - 15 Oct 2003

Although a very nice and useful feature complementing the TWikiMission, it should not go into the core because it is way out of line with the TWikiSystemRequirements (discussed in RequiredEnvironmentForTWiki). As John pointed out, we should make use of the Plugin API. The purpose of the Plugin API is to exteend TWiki in line / not in line with the system requirements.

As for storing Plugin internal (or visible) data, we need a RecommendedStorageOfPluginData.

-- PeterThoeny - 16 Oct 2003

on Plugin API allow for extensions of this type, why not go this route first?, well:

  • Its is not that because it is technically possible that we should do it. We must think first of usability issues. The documentation issue is an important one for options of functionalities like this one IMHO. This could means we should design "documentation hooks" for plugins too?
  • This does not requires anything on the browser. Old browsers (lynx, NS4) do not see a button and can still edit the date field by hand as before. So this do not raises the TWikiSystemRequirements (just like there is already some javascript in standard twiki to augment functionalities). I took care to not have the JS code downloaded if the date field was not used.
  • I think the Plugins API do not scale in the number of plugins (see my arguments in EmptyOoPluginDev), but this is not an issue as it is an implementation problem that can (should :-) be fixed.
  • (off topic) One could argue that Enabling/Disabling features like this may belong to the skin rather than the global installation of a plugin. We should devise a way to enable "plugins" via the skin too rather than the global WebPreferences, but how? For instance going full CSS2 and only supporting opera and firebird seems logically a skin decision, not a site-wide option.
One suggestion: basically this feature requires adding two parts to TWiki code (core and/or plugin): CSS+JS declarations in the HTML header, and some code outputted by the TWiki code on the date control. Maybe the logical solution is to have the code check for the skin supporting this jscalendar twiki feature to output the additional data? (for instance looking for <jscalendar_on /> in the loaded template (ugly), or a custom comments as in <!--twiki:jscalendar--><!--twiki:noimages--> or (preferred) the presence of a custom meta tag as <meta name="twiki" content="jscalendar,noimages"> ?

Note: this issues are important, it should allow us to get rid of the ugly skin-specific code in bin/view like:

        if( $skin =~ /^rss/ ) {
            $tmpl =~ s/<img [^>]*>//g;  # remove image tags
by replacing it by something like:
        if( TWiki::twikiSkinOption("noimages")) {
            $tmpl =~ s/<img [^>]*>//g;  # remove image tags

Note that in my current implementation I do in the opposite way: the core code (in bin/view for EditTablePlugin, and in /bin/edit for Forms) checks that we are editing a date topic, by a flag in $query that can be set by the rendering code of core ( Forms.pm ) of a plugin (EditTablePlugin), and in this case add the header code before </head> in the template.

On the topic at hand, maybe we could decide to document the date field type in the core, and moving the jscalendar code to FormFieldsPlugin ? We would add in the core documentation that some browsers may show additional interactive controls, for instance if the FormFieldsPlugin is installed ? I will do it that way for v2 of the patch if we see no better route before that.

-- ColasNahaboo - 16 Oct 2003

As a rule of thumb, I would like to see more Plugins shipped with TWiki and have more enhancements in Plugins and Plugin API. Eclipse is based on a relatively small framework, everything else are Plugins. This scales better and reduces the complexity of the core. For example, the WikiTablesNeedRowspanning feature is now in two places: in the core and in the TablePlugin; the Plugin should be shipped with TWiki, and the feature should be taken out of the core.

-- PeterThoeny - 16 Oct 2003

I agree, but Eclipse plugins have a much bigger granularity, which helps a lot on the documentation problems (having the doc for the perl mode as a separate document is not problematic), and Eclipse provides its integrated documentation system. And performance issues are no problem as user expect Eclipse to have big loading times (like small core + big addons systems like emacs) (and they stay in Eclipse for days), unlike web pages, and Java has a lot of technical solutions for on-demand loading.

I do not oppose to Plugins in general, I am just wary on the problems very fine-grained plugins pose in:

  • performance when unused: loading time, calling hooks in inner high-usage rendering loops
  • documentation: users want a goal-oriented synthetic doc (wizards, howtos), not a fragmented implementation description
  • testing: the more plugins you have, the harder it will be to check that one doesn't break the other
We should try to address these issues before going overboard with plugins, or draw a line of the acceptable granularity of plugins.

-- ColasNahaboo - 16 Oct 2003

I think Colas is right when he says we need documentation hooks for Plugins. An easy start would be some specific variables on specific documentation topics that Plugins can add to.

-- JohnTalintyre - 16 Oct 2003

Martin, added "-MC" signatures to your comments on my 15 Oct post... I only saw them now smile

-- ColasNahaboo - 16 Oct

Would it be possible to call this Date Picker from within ActionTrackerPlugin, to set due dates?

-- SamAbrams - 02 Jan 2004

Is this Feature really at 0% Progress? If it is could it be defered to the next release?

-- SamHasler - 13 Jan 2004

For forms this can simply be put in FormFieldsPlugin.

-- JohnTalintyre - 13 Jan 2004

Bump feature topic marked as scheduled for CairoRelease with 0% SpecProgress

-- SamHasler - 20 Apr 2004

Updated Colas' script to Cairo beta. Integrated EditTablePlugin. Use Colas' zip file, but patch with attached diff file and use the attached templates/jscalendar.tmpl file to reference the jscalendar files (I actually stored them in %PUBURL%/jscalendar).

Using this configuration, one can use a jscalendar on any edit or view page (the view page may sound surprising; there are two obvious applications: EditTablePlugin and flattened calendars).

-- ThomasWeigert - 06 Jun 2004

There is a mismatch in the versions of jscalendar included in Colas's zip file (0.9.3) and EditTablePlugin (0.9.5). If you apply Thomas's patch above things break because the date formatting strings have changed between version 0.9.3 and 0.9.5.

-- DeanCording - 20 Jun 2004

Dean, could you please explain what you mean by "things break", as I have this running on my system. If you could give me a better indication what you observe, I can see what is wrong and fix the patch...

-- ThomasWeigert - 20 Jun 2004

IMHO integrating this in the core would be a mistake. JSCalendar is already shipped as a contrib (JSCalendarContrib) for the very reason that not everybody wants to make the performance/ease of use tradeoff this way; some of simply don't need or want the date picker. What is really required is a strategy for integrating type-specific form data handling into form presentation and editing. This should be done as a plugin; perhaps a plugin that handles a range of data types, not just dates, like the FormFieldsPlugin.

-- CrawfordCurrie - 08 Sep 2004

Set to FeatureDone and the progress fields to 100% so that the table in CairoRelease looks nice.

-- SamHasler - 10 Sep 2004

I have made a new patch,JSCalendarContribForms.diff based on the code in EditTablePlugin. It notably reuses the setting variables in TWiki/TWikiPreferences: JSCALENDARDATEFORMAT JSCALENDARLANGUAGE JSCALENDAROPTIONS.

It supposes you installed JSCalendarContrib and makes use of its files. It only changes the Edit view (tackling the View view should be done in cooperation with the EditTablePlugin.

NOTE the version has changed from the old one I made. You must change the date format definitions in your topics. For instance, I used ISO dates, and I changed y-mm-dd to %Y-%m-%d in all user topics (web forms).

-- ColasNahaboo - 06 Jan 2005

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdiff JSCalendarContribForms.diff r1 manage 3.4 K 2005-01-06 - 18:43 ColasNahaboo for Cairo, uses the JSCalendarContrib
Compressed Zip archivezip JsCalendar.zip r1 manage 232.0 K 2003-10-15 - 15:44 ColasNahaboo patch to Beijing, v1
Edit | Attach | Watch | Print version | History: r33 < r32 < r31 < r30 < r29 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r33 - 2008-10-06 - RobStewart
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.