The use case is the polling/voting extension Rob and I have been
discussing off-list. The prototype is in use on this page (warning:
takes a long time to load):
http://ecoliwiki.net/colipedia/index.php/
Are_these_really_transcription_factors%3F
The poll is set to give a please log in message instead of the voting
menu and button if a non-logged in user clicks the vote button. This
state gets cached and after logging in, a purge is needed to see the
voting stuff again. In the example page, the results are shown by
default, but I suspect people would prefer something that shows
results only if you've already voted... which would be another state
that the page would get stuck in due to caching.
If a user clicks vote, a hidden input sends a purge to update the
totals. But anything that locks the polls into an unusable state
gets stuck.
In this particular use case, the really long ballot has to be on a
regular page instead of a special page because we want people to be
able to add comments and references. Invalidating the cache seemed
like a solution even though I'd rather have it pull from the cache if
users are not clicking on the vote button. I think the ideal
behavior would be for the page to use the cache for a new view, to
update the cache for a new vote, and to show something that doesn't
get cached for an illegal vote. Perhaps this is a job for AJAX or
non-AJAX javascript and I should leave caching alone?
Jim
On Aug 11, 2007, at 1:05 AM, Rob Church wrote:
On 11/08/07, Frederik Dohr <fdg001(a)gmx.net>
wrote:
There's a function invalidateCache() which
does the following:
Title :: newFromText($titles[$i])->invalidateCache();
Title::invalidateCache() will not turn off the parser cache for a
specified page. What it does is updates the page.page_touched column
of the corresponding page, forcing existing cached copies to be
discarded, and will send appropriate purge notices to configured Squid
servers.
In code, it's quite possible to instruct the parser not to cache the
current output, using $parser->invalidateCache(), where $parser is, of
course, the current parser as passed to the parser function or tag
callback.
This means it's quite trivial to write something to handle <nocache />
or even __NOCACHE__, although there's nothing official of that nature,
because we prefer to encourage developers to ensure that caches are
used, and remain coherent.
Rob Church
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
=====================================
Jim Hu
Associate Professor
Dept. of Biochemistry and Biophysics
2128 TAMU
Texas A&M Univ.
College Station, TX 77843-2128
979-862-4054