[pmwiki-users] Announcement: Page Variable Extensions recipe

[Martin Fick]

--- Dominique Faure <dominique.faure at gmail.com> wrote:
> I should apologize that I borrow initial idea from
> some mailing list
> threads which should also led you to your recipe
> ;-).

Ideas are great, but you wrote the code (much better!)
:)  The devil is in the details right? 
Combining those details is another challenge...


> 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'.

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...


> 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 for syntax, in this case I think the task is a very
simple one and deserves a very simple wiki-like
syntax.  There may be some potential issues
(conflicts) with my syntax, but I have yet to think of
any.  I also think it is a little intuitive (of
course, one person's intuition...) and fairly clean. 
But since your first impression may have been
different (or maybe just influenced by your motive
above?), I could be convinced other wise.

I hope I didn't jump the gun by trying to combine two
things that really should be separate?  As they say, 
things should be as simple as possible, but no
simpler!


> 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.

> In the same mood, we may also handle session datas.

Session data was a good idea. :)

-Martin


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com