At 2/28/2005 04:59 AM, Brion Vibber wrote:
Sebastien BARRE wrote:
[snip]
Note that this code is slightly identical to
Title::invalidateCache.
[snip]
That way, cur_touched is always fresher than the
cache,
and the page always gets re-created. Am I missing something ?
While this might happen to work, it's not really a very good solution;
the technique is very oblique (which would make it hard to maintain),
and it'll produce a lot of unnecessary writes to the database.
Oh I agree, it's definitely a hack, and is not intended for a large web
site, but as much as I like MediaWiki, it was the only quick workaround I
could find to go around what I consider a (small) design flaw: to my
opinion, the current extension feature is rendered pretty much useless by
the current caching mechanism.
Instead, you should try adding a "don't cache
this page" flag to the
parser, which an extension could trigger.
There is such thing I assume, the invalidateCache() method is close enough,
am I right ? But there is no way to call it early enough. What might (also)
be missing, I think, is more hooks so that extensions can have a chance to
trigger code at earlier stage in the parsing process. Actually as far as
I'm concerned, a safe assumption would require less work: if an extension
tag is detected in a page, it should always be re-created (unless some
global flags is set, if you really want to disable that on large project
like Wikipedia).
--
Sebastien Barre