Item11020: Date field is not formatted according to JSCALENDARCONTRIB_FORMAT setting

If JSCALENDARCONTRIB_FORMAT is set to a specific date format, for instance a MySQL timestamp %Y-%m-%d %H:%M:%S, a data form with a date field is still rendered in the default date format set in configure. The specific format is only set when clicking on the date button, which means a couple of extra (redundant) clicks.

And it is not desirable to change $Foswiki::cfg{DefaultDateFormat}, because then even the dates in the breadcrumb are shown in that format.

So JSCALENDARCONTRIB_FORMAT should not only configure the date picker format, it should also format the shown date in the textfield.

-- ArthurClemens - 04 Aug 2011

Reopening it. Seems to be totally broken for me now.

What am I doing wrong:

%INCLUDE{ 
   "%SYSTEMWEB%/JSCalendarContribInline" 
}% 
%INCLUDE{ 
   "%SYSTEMWEB%/JSCalendarContribInline" 
   section="initCalendar" 
   id="cal_val_here" 
   format="%e %b %Y" 
}% 

<input type="text" class="foswikiInputField" id="cal_val_here" value="3 Nov 2011" /> 
<input type="image" src="%PUBURL%/%SYSTEMWEB%/JSCalendarContrib/img.gif" onclick="javascript:return showCalendar('cal_val_here','%e %b %Y')" /> 

-- MichaelDaum - 08 Aug 2011

This works...

Now working on another issue that the calendar jumps to another date if clicked subsequently.

-- ArthurClemens - 08 Aug 2011

I now get this:

Uncaught TypeError: Property '$' of object [object DOMWindow] is not a function

That's because the code doesn't stick to our JQueryCodingStandards and thus fails with NoConflicts enabled.

As a core developer working on js, please always enable NoConflict in your configuration to make sure these things won't slip in again in the future.

Besides, the above example still does not correctly initialize the formfield. It overrides its value with the current date, which seems to be some sort of fallback. Where's the error in that respect: in the example or in the contrib?

-- MichaelDaum - 09 Aug 2011

While I found the error for these two, there still is another strangeness related to the above example: if I edit and save a test topic with the above content, then the first view won't establish a click handler for the image. Reloading the page makes it work again...

Chrome emits an error saying:

Refused to execute a JavaScript script. Source code of script found within request.

JSCalendarContrib doesn't work at all in firefox:

cal.sel.onchange is not a function

Please, let's use the jQuery event handlers for these kind of things as jQuery comes with all sorts of x-browser fixes for these kind of things. Not sure what line 7 is for anyway. From what I see these few lines can be removed. Any other code listening for a change event should use jQuery(el).change(function()) to establish a callback.

-- MichaelDaum - 09 Aug 2011

For the most part this code is a reshuffling of what was there, it is not a complete (better) rewrite. So

cal.sel.onchange is not a function

would have occurred earlier. I don't see that error here BTW.

About the error Refused to execute a JavaScript script. Source code of script found within request:

[14:00:13] <ArthurClemens> it works when coming from wysiywg
[14:00:13] <ArthurClemens> general cause of the issue: http://axonflux.com/bookmarklet-hackers-you-should-know-about-thi
[14:00:53] <ArthurClemens> Chrome refuses to execute a piece of javascript code in the following sequence of actions:
[14:00:53] <ArthurClemens> The user has an input field on the page where s/he can enter and submit content.
[14:00:53] <ArthurClemens> The user enters javascript code wrapped in <script> tags and submits the page.
[14:00:53] <ArthurClemens> The next page that opens after submission has the exact same javascript on the page.
[14:06:36] <ArthurClemens> the problem exists in version of 11 Apr, so it is not recent
[14:06:56] <ArthurClemens> somehow nobody has noticed before
[14:08:17] <ArthurClemens> the problem is caused by the image onclick javascript. you use a ADDTOZONE to put the click in head the problem is gone
[14:09:54] <ArthurClemens> another trick is to make the javascript unique: onclick="return showCalendar('cal_val_here','%s', '%GMTIME{"$epoch"}%')"

-- ArthurClemens - 09 Aug 2011

Documented the Chrome error.

-- ArthurClemens - 09 Aug 2011

I'm not sure if it's this work that has done it, but now an empty date field will be pre-populated with Jan 1 1970 on edit. Which is a change in behaviour (and an unwelcome one for the FeatureProposals DateOfCommitment field

-- PaulHarvey - 10 Aug 2011

Good catch. Fixed.

-- ArthurClemens - 10 Aug 2011

The contrib now uses the new Foswiki Date parsing lib in foswikiDate.js.

-- ArthurClemens - 18 Aug 2011

These changes have been reverted in release branch due to problems in Item11290. We also feel that the contrib does too much in setting date formats. See ConvertDatesToISO for a discussion.

-- ArthurClemens - 29 Nov 2011

Commenting is disabled while not logged in