[pmwiki-users] Announcement: Page Variable Extensions recipe

[Dominique Faure]

On 7/3/06, Martin Fick <mogulguy at yahoo.com> wrote:
[...]
>
> I don't like that syntax (or the one proposed in the
> follow-up email, it does not mean much to me.  The
> only way I can understand what it is when I realte it
> to your motive which I think I understand...
>

My motivations were primarily to provide the missing features I needed
to page variables, aka initialization of arbitrary variable and
"not-so-simple" value manipulation ;-). This led to the initial
version of PageVarExtension, with the drawback to stay confined to the
same wiki page. Thinking of the PHP $_REQUEST array, I just wanted to
get the best of two worlds.

>
> > But, I'm not very keen on the syntax extension you
> > defined, since it
> > tends to pollute the page directive namespace,
> > providing too much ways
> > to address things which have the same
> > nature/purpose.
>
> I had a similar motive when designing the
> pagelisttemlpate recipe.  I wanted my recipe to not
> have much of an impact on regular pmwiki syntax, it
> was Patrick who later encouraged simplification and
> did most of it.
>
> I think that your recipe has two major differences,
> one of syntax and one of method.  Your method is to
> assign them to variables and then use those variables
> where as mine is to simply use them.  I am not
> convinced that the extra step provides any real
> benefit, does it?
>

As you guessed, the data flow I was thinking of is:
1/ [External world -> Wiki] Initialize variables from various sources
such as url, form datas,...
2/ [Wiki -> Wiki] Then, do what you want with your variables and only
them (including value computations via functions suffixes).
3/ [Wiki -> External world] And optionally, make your data flow out of
the wiki with the help of hidden form input fields or using specific
directives such as (:cookie...:) or (:session...:).

The benefits I expected were:
* code/core-features reuse: PmWiki already implements variables. Why
reinventing equivalent things instead of binding itself to those
Patrick already made (they are often so smartly defined that such
bindings are really easy)?
* side-effect corollary #1: existing features/behaviors (aka standard
page variables) are already (well) documented for the user.
* recipe improvement: as the core itself, I think recipes need to
provide a wide configuration/adaptation level. We are now thinking of
variable persistence through cookies or session datas, why not a bunch
of AJAX for tomorow?

Well, with all these background considerations, I planned the
(:cookie...:) and (:session...:) directives later and concentrated on
the external source handling in variables initialization. I already
with the following constraints:
1/ handle several initialization schemes (get, post, request,...)
=> centralized handling.
2/ interfere as little as possible with user initialization
=> the syntax should be not too common but still readeable ;-)

the full syntax will surely be something like:
(:set var='(http:get param_name) default_value' ...:)
or:
(:set var='[http:get param_name] default_value' ...:)

with http:get, http:post, http:request, http:cookie and session:data
as predefined <scheme>:<function>

>
> > The cookie handling would need more parameters to
> > manage domain and/or expiry.
>
> I considered these and decided that they were a little
> bit complicated to deal with simply (for now).  The
> thing that really through me off was date formats...
> I am not opposed to adding a good clean syntax for
> these features, but I took the easy approach for now.
>

Concerning times and dates, the recipe (already) provide a {$Now}
variable to fetch current timestamp, and I added some numerical
postfix functions:

(:set n={$Now}:)
* now: {$n} ({$n:ftime '%D-%T'} {$n:gmftime '%D-%T'})
* later: {$n:+ 3600} ({$n:+ 3600:ftime '%D-%T'} {$n:+ 3600:gmftime
'%D-%T'})

Which render as:

now: 1152015848 (07/04/06-14:24:08 07/04/06-12:24:08)
later: 1152019448 (07/04/06-15:24:08 07/04/06-13:24:08)

and may directly used as a directive parameter. This will be available
in the next release.

Regards,
Dom