Created Item3068 to capture a further enhancement suggestion by MD
For
JSCalendarContrib, it would be nice to have a form field dependent format. But the only place where we can define this is in the form definition. The most natural would be the attribute, but that is set up to take single character codes to indicate something (e..g,
M
for mandatory fields).
The single character code was probably a dumb idea, but we are probably saddled with that now. Better would have been the standard attribute syntax (e.g.,
mandatory="yes"
).
So really the only flexible field is "size", which somewhat makes sense for the date field, as size is determined by the format. But the size field is piped through
_cleanField
which wipes out all but alphanumerics.
I suggest we do not send size through that filter, so that we could define a field to be
| Date | date | 10, %e %b %Y | 12 Aug 2006 | The starting date | M |
Why do you thing the single character code prevents a richer attribute syntax? If you think of
M
as being shortand for
M="yes"
there is no problem. You could write:
| Date | date | 10 | 12 Aug 2006 | The starting date | M format="%e %b %Y" |
It so happens that the standard attrs parser can be used in a "friendly" mode, as used by the action tracker.
cd
to your
lib
directory and try this:
perl -I . -e 'use TWiki::Attrs;my $a=new TWiki::Attrs("m format=\"%e %b %Y\"", 1);print $a->stringify(),"\n";'
(friendly mode currently only recognises lower-case switch names, but can easily be modified to recognise upper-case as well.)
Reprioritised to Enhancement.
CC
Yes, your suggestion is an excellent one, and the change to the TWiki::Attrs is trivial (actually it is not clear from the doco why the friendly attr syntax does not recognize Booleans starting with upper case). --
TW
We would have to change the Form code to use TWiki::Attrs rather than just looking at a match for
M
, for example. Otherwise it would pick up any m charactet in other form attributes.
Rewrite the handling of attributes so that we could extend the attribute field to be flexible and use additional terms in the "friendly" syntax of tag TML parameters, as suggested by
CC.
No changes are made to
JSCalendarContrib at this point.
4.1.0 released --
KJL
I am reverting this change because of
Item3685. First I wanted to fix the code but the more I look the more this just looks like broken compatibility. --
KJL
The problem was that long in the past, all spaces are removed from attributes when stored to disk. This is clearly wrong, but was not noticed before this new feature. Three lines in
Form.pm
need to be changed to solve this problem.
Writing additional test cases. Change the priority to
Normal
as this is now not an enhancement any longer (was in 4.1, and other features that are in the code base rely on this now). --
TW
The history is long and convoluted, but with a recent refactoring the core doesn't need a dependency on
JSCalendarContrib any more. Date fields are supported if the contrib is installed, end of story.
Closed.
CC