The foswiki svn repository is obsolete. Developers should register for a http://github.com/ account for commit access to foswiki project. Github is ready for updates.

Item10274: Collision between Date formatting and Wiki variables

Priority: CurrentState: AppliesTo: Component: WaitingFor:
Normal Closed Extension EditTablePlugin  
Given

%EDITTABLE{format="|text|date,15,,%Y%m%d|"}%

Foswiki interprets %Y% (a Wiki pre-defined variable) instead of %Y (a date format variables) and tries to stuff an img tag into the date field.

-- VickiBrown - 20 Jan 2011

I tried %Y but that put a literal %Y into the field (actually it put %Y into the field).

I tried %Y%m but that put <nop> into the middle of the date string. (e.g. 2011<nop>0113). It looks OK on the front end, but really weird on the backend and this would not play well in a SEARCH.

-- VickiBrown - 20 Jan 2011

It looks like we need to make the parser aware of the format to not expand the %Y%.

-- ArthurClemens - 20 Jan 2011

Yeah, I think date format should take precedence over variables...

-- VickiBrown - 20 Jan 2011

The fact that the macros can be expanded inside another macro, and in particular in the "format" part of it, is a Foswiki feature.

By preventing the expansion there, wouldn't we be making difficult to deal with a use case where, for instance, I want to display the dates in red if it is a past date? I have to use %IF%, %CALC%, RED%.

Vicki, just by using %Y-%m-%d you avoid this problem, and you can sort and compare the dates in this format quite easily.

-- RaulFRodriguez - 20 Jan 2011

Currently you cannot put a macro around the date format. The format string is directly passed to JSCalendarContrib and it breaks if the format cannot be read.

-- ArthurClemens - 20 Jan 2011

Using <nop>s works for inline calendar forms, couldn't it work for EDITTABLE date forms too?

No it doesn't, but it should, shouldn't it? wink

Of course you could try to set the system default calendar format to %Y%m%d, then you wouldn't have to specify the format in the EDITTABLE, right?

-- FranzJosefGigler - 20 Jan 2011

Fixed in release 4.39.

I have added this to the documentation:

In some rare cases, if you pass the date format in %EDITTABLE{format="..."}% and the date format components are adjacent, you must escape the % characters to $percnt to prevent that the components are expanded as macros. For example:
%EDITTABLE{format="|date,15,,$percntY$percntm$percntd|"}%

-- ArthurClemens - 20 Jan 2011

Great!

It looks like you did the changes to %EDITTABLE% (correct me if I am wrong).

As this problem is relevant to the date and time format specifiers of JSCalendarContrib, shouldn't it be addressed at the level of JSCalendarContrib?

Thus the problem for JSCalendarContrib would be solved whether is is called from %EDITTABLE% or used inline, or from another macro.

It should then be documented in the JSCalendarContrib documentation after the list of format specifiers.

Please note that the documentation in JSCalendarContrib/data/System/JSCalendarContrib.txt uses a %$POD% directive to include the detailed documentation embedded in the code in JSCalendarContrib/lib/Foswiki/Contrib/JSCalendarContrib.pm.

-- RaulFRodriguez - 21 Jan 2011

JSCalendarContrib is just a contrib. It provides javascript, but does not have a postRenderingHandler to clean up things. Users are able to create the date widget by writing:
<input type="image" src="%PUBURL%/%SYSTEMWEB%/JSCalendarContrib/img.gif" onclick="javascript: return showCalendar('cal_val_here','%Y%m%d')" />
without any plugin to 'correct' this input.

Users do have the possibility to put nops in between the format tokens.

-- ArthurClemens - 21 Jan 2011

 

ItemTemplate edit

Summary Collision between Date formatting and Wiki variables
ReportedBy VickiBrown
Codebase 1.1.2, trunk
SVN Range
AppliesTo Extension
Component EditTablePlugin
Priority Normal
CurrentState Closed
WaitingFor
Checkins Foswikirev:10586 Foswikirev:10587
TargetRelease patch
ReleasedIn 1.1.3
Topic revision: r13 - 16 Apr 2011, KennethLavrsen
 
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement. Creative Commons License