Created Item3068 to capture a further enhancement suggestion by MD
, 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,
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.,
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
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
as being shortand for
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.
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.
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
, 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
need to be changed to solve this problem.
Writing additional test cases. Change the priority to
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.