But I don't think that's a problem at all - the main functionality of this word would be achieved. It could be added as a parser extension (i.e. not actually written into MediaWiki) that we can install on the projects for all the useful uses it can be used for?
On 15/11/2007, Mark Clements gmane@kennel17.co.uk wrote:
"George Herbert" george.herbert@gmail.com wrote in message news:38a7bf7c0711141448x63fce7d8hf6798d840a49c0be@mail.gmail.com...
I am not a Javascript guy, so I apologize in advance if this is a dumb question, but... Is it possible to make {{USERNAME}} some javascript
which
expands it on the client side, so the server just provides that JS to
the
browser and lets you figure it out? That would be the same JS code for everyone, so the underlying parsed article would stay in memcached unchanged...
I don't know if JS can carry the equivalent of a global variable within
the
page, so I'm not sure if you could set such in the already per-user generated header stuff and then expand it with JS in the fixed page
content
part. I guess that's what I'm thinking of here. But I freely admit
that I
don't know if that's possible or not.
There is no need for javascript. It would be trivial for the main parser to ignore a {{CURRENTUSER}} magic word, and then for this to be replaced when the HTML page is compiled from it's various sources (using 'anonymous user' or something if it was an anon).
This has already been proposed in this thread somewhere as a solution that wouldn't break caching. However, it means that constructs that depend on the value when the wikitext is being parsed (e.g. parser functions, such as {{#ifeq:}}) won't work as expected, because {{CURRENTUSER}} is exapanded at the end, not the beginning, of the parse.
- Mark Clements (HappyDog)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l