Cairo apparently includes the EditTablePlugin. One of the recent additions to this plugin was the ability to edit dates using jscalendar. I think it is not appropriate to make this calendar unique to the EditTablePlugin. Any form that has a date would benefit from this plugin. Further, EditTablePlugin uses the jscalendar slightly different from the one that is on sourceforge.

May I recommend the following:

• Reference the official version of jscalendar
• Detach from EditTablePlugin
• Integrate it into the view and edit scripts (i.e., lib/TWiki/UI/Edit.pm and View.pm as well as the form handling

This form of integration is also outlined in JavaScriptDatePickerForForm. I have used the jscalendar in this manner for a while now, and it is better handled in the generic manner, I would venture.

-- ThomasWeigert - 05 Jun 2004

Sounds like a prime candidate for SharedCode to me.

-- MattWilkie - 06 Jun 2004

Thomas implies its potential usefulness for form editing; in fact, the date type is one of the most widely useful types, and the strongest argument (besides integer ranges) for stronger data typing in forms. Having said that, here are the arguments against adding jscalendar to the core:

1. It's IE only AFAIK (I never got it to work on Konq), and therefore violates the portability principles of the core.
   • It works fine with Mozilla based browsers. As Konq JS library gets better, this shouldn´t be a problem either. At least the author says: It works with Mozilla, Netscape >= 6.0, all other Gecko-based browsers, Internet Explorer >= 5.0 for Windows, Opera 7, Safari and Konqueror -- AU
2. It's very late for making such a big change to Cairo.
3. Support for typed data in forms should be done properly, not piecemeal. As well as date types, there should be ranged integer and float types, legal wiki names, URLs.

If JSCalendar support is put into SharedCode now it would at least be useable by the plugins, and could be moved to the core for Dakaar. However: Peter is the author of EditTablePlugin; I don't know how keen he would be on this approach given the concerns he has voiced about SharedCode. Peter?

-- CrawfordCurrie - 06 Jun 2004

I can see your points regarding Core. However, having this feature just in EditTablePlugin is strange also. The first thing I did when it was added to EditTablePlugin is take it out and generalize it to all forms. I have not studied FormFieldsPlugin yet to see whether this would be a more generic vehicle to use formm typing. This is implied in JavaScriptDatePickerForForm, but reading the description of this plugin I find it difficult to make the connection.

But it is definitely frustrating for a user to be able to pick dates using jscalendar in one kind of application, but not in others. It is also frustrating for implementers, as the jscalendar enforces in a rudimentary manner a particular date format, which otherwise one would have to write extra code for (yes, I know, jscalendar does not literally enforce it, but chances are pretty good that people will use the format given by jscalendar).

-- ThomasWeigert - 06 Jun 2004

OK, I went through FormFieldsPlugin to see how we can integrate jscalendar there. In the process, I discovered that this plugin does not work any more as functionality that it relied on was deleted from core. I managed to get jscalendar to work along the lines envisioned by this plugin, albeit I have not tried to fix the rest of the plugin. However, there is a problem as compared to doing the form field extensions in core:

• It is not possible (at least I have not found a way to do so) to insert the code setting up the jscalendar only when jscalendar is actually used. There is no means of communicating this information from renderFormFieldForEditHandler to commonTagsHandler which is the only place where we have access to the HTML header.
• The plugin cannot be sensitive to the skin as the skin variable is not passed into the plugin handlers.

-- ThomasWeigert - 07 Jun 2004

I sympathise. What you really want to do is subclass the form editing stuff and ask TWiki to use the subclass if its IE. But you can't. Did you fix FormFieldsPlugin? Are any extensions to SharedCode required? If so, feel free to make them.

-- CrawfordCurrie - 08 Jun 2004

Re "did you fix...": Yes and no. I made it work with providing jscalendar as a date field. I also made it work with the color picker. I did not tackle the multi-field as I did not understand what it was meant to do; I also thought that adding a $user variable was somewhat questionable, as in my case that would mean several thousand added lines in each topic.

But the real problem is this: I can make it work within the confines of a plugin by adding Javascript to every topic edited, whether it is needed or not. What I would like, and this is actually what I did, is add a functionality to TWiki.pm that allowed me to add the Javascript supporting the extensions only when they are used. However, this cannot be done by plugin only (I think) as the right time to add this is after the form handling, but at that time the plugin API is not called any more. During the form handling we don't have access to the whole topic.

I'll look at SharedCode for reuse opportunities...

-- ThomasWeigert - 08 Jun 2004

I just bundled jscalendar-0.9.6 in SharedCode.I needed it for the ActionTracker, and felt that shipping yet another copy in the plugin distribution was not such a great idea

-- CrawfordCurrie - 06 Aug 2004

Crawford, this is good.

But now it should be pulled out of EditTablePlugin, in particular, as these do not seem to be in synch. If we ship EditTablePlugin with Cairo, it should not have jscalendar embedded.

-- ThomasWeigert - 08 Aug 2004

I think we are on the right track. However, details on how to manage ContribPackages needs to be fleshed out. The proposed approach to combine everything together in one big SharedCode is not maintainable and will bite us in the future.

-- PeterThoeny - 08 Aug 2004

To make including javascript simpler, here is one possibility:

• Like STARTINCLUDE/STOPINCLUDE, create two more standard pattern tags: STARTHEADER/STOPHEADER.
• Introduce a new macro %HEADER% (like %TEXT) that will pick up info that is placed between START/STOPHEADER. This is put in template.
• Alternately INCLUDE{AddJSCalendarToCore pattern="..."} also works. But this will probably read to an extra file read.
• To allow more flexibility, the default algorithm could also include headers from parent topic, web preferences and twiki preferences topics.

-Vinod

-- VinodKulkarni - 07 Sep 2004

A much simpler approach is all that is required. All TWiki has to do is lift out <script>...</script> tags, in almost exactly the way it does verbatim. Use of script is a pretty specialist thing; the standard HTML tags are already perfectly suited to the job.

-- CrawfordCurrie - 07 Sep 2004

I reckon the original question here is answered by JSCalendarContrib and DateFieldPlugin, so I'm going to shut down this topic by setting it to FeatureDone.

-- CrawfordCurrie - 13 Feb 2005

JSCalendarContrib has been packaged up as AddOnPackage in JSCalendarAddOn. A patch to EditTablePlugin is provided also which leverages the contrib.

-- ThomasWeigert - 13 Feb 2005

JSCalendarContrib is now part of the DakarPackage, and the version of EditTablePlugin shipped with the kernel uses it. DevelopBranch only, of course.

-- CrawfordCurrie - 21 Mar 2005