"Adrian Holovaty" <[EMAIL PROTECTED]> wrote
in message
news:[EMAIL PROTECTED]
>Finally, along those lines, we could introduce a vary_on_get
>decorator, which, used with the NO_GET_PARAMS setting, would be an
>opt-in signifying a view *does* rely on query string. This could be
>for stuff like search engines, which do vary based on the query string
>(e.g. /search/?q=foo). In this case, though, it'd be nice to be able
>to specify the variables that are valid. For example, with the
>decorator @vary_on_get('foo', 'bar'), the cache would store separate
>pages for /search/?foo=1 and /search/?bar=1, but it would use the same
>cache for /search/?foo=1 and /search/?foo=1&gonzo=2, because "gonzo"
>isn't specified in "vary_on_get" and thus would be ignored.
I like @vary_on_get(). IMHO, it covers a lot of real-life scenarios.
Additionally I would be nice to be specify life time of cached copy from
view. In this case we can dynamically assign bigger time to least likely to
change items based on their content. Example: recent articles can be
modified, while old articles are unlikely to be changed now (see
http://code.djangoproject.com/ticket/590).
One more wish: add "clear the cache" button to Admin. I don't ask for
sophisticated cache management (it would be nice to have, but...). Even
simple thing will help a lot. ;-)
Thanks,
Eugene
