On Mon, 2009-08-03 at 01:00 -0400, Nick Fishman wrote:
> > 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.
Right. I hadn't thought of (ab)using it like that to just cache a random
variable (why not do it in the view in that case?!). It's more intended
for caching rendered template fragments and I thought you'd be able to
tell when the first thing was a number it's a timeout and when it's a
string it's a template fragment.
> 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.
Or you could do it the easy way and spend three minutes writing a
template tag that uses the default cache value. Remember, you are
*encouraged* to write your own template tags to scratch itches. You
already have an example to work from. :)
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
