[pmwiki-users] {(...)} markup recipe available

Patrick R. Michaud pmichaud at pobox.com
Thu Apr 12 10:23:55 CDT 2007


On Thu, Apr 12, 2007 at 11:53:35AM +0200, Roman wrote:
> The only comment I have is that I would transpose parameters of ftime
> expression so second parameter (format) could be omitted. That would
> allow users to specify only "when" parameter, for example {(ftime
> "next Monday")} without the need to always specify format. In this
> case, default format defined by administrator would be used.

I went with this approach because it's not obvious to me that
omitting the format parameter will be all that common -- I can
imagine situations where one would like to be able to specify format
without the need to always specify the time.  But there are a huge
number of possibilities here, with no real obvious choice, so I'll
outline a few of them and see if anyone has strong preferences.

0.  We could just leave things as they are now.  At the moment the
    way to specify "default format" is to put an empty format
    argument:

      {(ftime)}                   # current time in default format
      {(ftime '' '+3 hours')}     # 3 hours from now in default format

1.  Because the percent-sign is very unlikely to appear in a 'when'
    specification, we could say that the first argument containing
    a '%' is the format string:

      {(ftime %F tomorrow)}       # tomorrow as yyyy-mm-dd
      {(ftime tomorrow %F)}       # also works

      {(ftime '+3 hours')}        # 3 hours from now in default format
      {(ftime %F)}                # current day as yyyy-mm-dd

2.  We can allow explicit "when=" and "fmt=" names on the arguments.
   
      {(ftime when=tomorrow)}     # 24 hours from now in default format 
      {(ftime fmt=%F)}            # current day as yyyy-mm-dd

3.  We could transpose the parameters (when first, format second)
    and allow an explicit fmt= to have the format go first:

      {(ftime tomorrow)}          # 24 hours from now in default format
      {(ftime tomorrow %F)}       # 24 hours from now as yyyy-mm-dd
      {(ftime fmt=%F tomorrow)}   # same

4.  We could keep the parameters as they are, and allow an explicit
    when= to have the when argument go first:

      {(ftime %F)}                # current day as yyyy-mm-dd
      {(ftime %F tomorrow)}       # 24 hours from now as yyyy-mm-dd
      {(ftime when=tomorrow %F)}  # same
      {(ftime when=tomorrow)}     # 24 hours from now in default format

5.  We can have special markup expressions to indicate the
    default format parameter:

      {(time '+3 hours')}         # time in default format
      {(isodate tomorrow)}        # same as {(ftime %F tomorrow)}
      {(isotime '+3 hours')}      # same as {(ftime %FT%T '+3 hours')}

6.  Various combinations of the above.


But ultimately the question of order for format and when comes
down to asking which is likely to occur most often:  (1) formatting
different time values using a common default admin-defined
format, or (2) specifying that the current time is to be displayed
in different formats?  I don't have a clear answer to this, so
hearing from others would help.  And if there's not a clear
advantage to one approach over the other, then consistency says
that we should probably use the same order of arguments that PHP's
strftime function uses, which has the format parameter first.

I think my personal preference at this point is a combination of
#1 and #2 above, where {(ftime)} uses the first argument containing
a percent sign as the format parameter, but the arguments can be
made explicit by adding "when=" and/or "fmt=" to the argument.

Pm




More information about the pmwiki-users mailing list