> and suggests otherwise). It might not be too difficult to add support
> for an optional timeout, although the error checking requires a lot of
> care.
I think that's the main problem. Since arguments to {% cache %} aren't
named, it doesn't seem possible to differentiate {% cache 500 key1
key2 %} from {% cache user.id key1 key2 %}. In the first case, 500
represents a timeout. In the second case, user.id might resolve to 500
and represent a _key_ rather than a timeout. I'm not sure of an
elegant way to deal with this.
I'll probably stick with setting a large constant in a
context_processor and using that as the "effectively expire never"
time. I'd have to use a similar trick when using the low-level cache
API, anyway.
Thanks,
Nick
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
