[pmwiki-users] Announcement: Page Variable Extensions recipe

[Dominique Faure]

On 6/30/06, Martin Fick <mogulguy at yahoo.com> wrote:
> Dominique,
>
> That is a very cool recipe!  Have you seen my
> HttpVariables recipe?  Before implementing that I was
> thinking of adding that functionality to your recipe.
> I think that I decided against it simply for naming
> reasons (they weren't actually page variables), but it
> might make sense to merge our recipes.  I am not
> particularly attached to mine, but it has a few extra
> nifty features that I would like to keep.  I don't
> like proliferating too many recipes.  What do you
> think?

I should apologize that I borrow initial idea from some mailing list
threads which should also led you to your recipe ;-).

> One feature I like is the ability to explicitly
> differentiate where the variables came from, GET,
> POST, COOKIES?  This really is reminiscent of the old
> days of PHP where everything shared the same namespace
> and then it was realized that it is often helpful to
> separate them.  Having separate namespaces can help
> prevent a user from overriding a page's intent with
> URLs.

I like the way you made it as it only deals with the arguments you
explicitely refers to (ie this protects the further page logic from
hand-crafted/mis-typed reference with unwanted variables initialized).
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 would prefer to improve the (:set ...:) directive to handle explicit
initializations from url/posts/cookies parameters with something like:

(:set v1='@(get param_name default_value)' :)

where you may replace 'get' by 'post' or 'req'.
The cookie handling would need more parameters to manage domain and/or expiry.
In the same mood, we may also handle session datas.

Regards,
Dom