[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