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
- Go to http://dynarch.com/mishoo/calendar.epl and download the actual calendar zip.
- Unzip it in an appropriate location: twiki/pub/TWiki/JsCalendar.
- Ensure the permissions are set right!
Edit.tmpl
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>
Form.pm
After:
...
if( $type eq "text" ) {
$value =~ s/"/"/go; # Make sure double quote don't kill us
$value =~ s/&/&\;/go;
$value =~ s/</<\;/go;
$value =~ s/>/>\;/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/&/&\;/go;
$value =~ s/</<\;/go;
$value =~ s/>/>\;/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\">
Calendar.setup({
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
});
</script>";
}
Test the installation
After these steps, make a Form-Topic which use the date-type see screenshot:
Have fun!
Tips:
- 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
Comments
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.
- 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
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
--
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