[pmwiki-users] MarkupExpressionsExtensions

Patrick R. Michaud pmichaud at pobox.com
Mon Apr 16 13:13:55 CDT 2007


On Mon, Apr 16, 2007 at 06:03:53PM +0000, Sandy wrote:
> Patrick R. Michaud <pmichaud <at> pobox.com> writes:
> > On Mon, Apr 16, 2007 at 08:28:30AM +0100, Hans wrote:
> > > Sunday, April 15, 2007, 10:41:08 PM, Patrick wrote:
> > > > (which is why PHP calls its variable $_SERVER).
> > > 
> > > Is there a need for a {(server ...)} markup expression? 
> > 
> > I don't see a need for a {(server ...)} markup expression, which is
> > why the core doesn't include it.    I was simply remarking that
> > if a recipe was going to provide one, it would be better to use
> > the HTTP protocol names instead of introducing aliases.
> 
> I prefer using the same vocab as the CGI interface, mainly because 
> it's one less vocabulary to learn. Neutral on page variable vs markup.

One nice thing about page variables is that they can be used
directly in $...Fmt strings and templates, whereas markup
doesn't always do that.

> Looks like the best bet is to pick one set and be consistent, 
> and include the rest of the terms in the documentation.

And since ultimately a lot of people have to work with the $_SERVER
variables, that seems like the best option.

> Security considerations? Would any of the $_SERVER variables give away
> information best kept private?

This depends on the application and administrator, but many admins
would definitely answer "yes" to this question (another reason for it
to be optional).

> Also, back-of-the-mind stuff, what about the other predefined 
> variables?

We could look at those as well... but at some point PmWikiPhilosophy
#3 applies.  So far there doesn't seem to have been much identified
need for them.  Ultimately PmWiki Philosophy #3 says that we add
features only when there's a definite and specific need for the
feature, as opposed to simply adding a feature because it
might be useful in the future.

Thanks!

Pm



More information about the pmwiki-users mailing list