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(a)kennel17.co.uk> wrote:
"George Herbert" <george.herbert(a)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(a)lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/wikitech-l