Re: Caching and logged-in users

[Håkan W]

Rajesh,

Thanks a lot for taking the time to explain, it helps a lot.

/Håkan

On Mar 9, 7:02 pm, Rajesh D  wrote:
> On Mar 9, 9:11 am, Håkan W  wrote:
>
> > Hi all,
>
> > I'm a bit confused about the caching. I've started using per-view
> > caching with the @cache_page decorator.
>
> > Now, if I add this to pages that return private content to logged-in
> > users, will it do the right thing and not show information for one
> > logged-in user to another? And it must not show logged-in content to
> > non-logged in users of course.
>
> First, add this to your settings:
>
> CACHE_MIDDLEWARE_ANONYMOUS_ONLY = True
>
> Even though this setting is for the cache middleware, the @cache_page
> decorator internally uses the same middleware code so the above
> setting will be honored by it.
>
>
>
> > Example:
>
> > @cache_page(3 * 60)
> > @login_required
> > def view(request):
> >    if request.user.is_authenticated():
> >       # show something that is "private" to this user...
> >    else:
> >       # show general stuff, for all non-logged in users
>
> With CACHE_MIDDLEWARE_ANONYMOUS_ONLY set to True, the @cache_page
> decorator will cache the anonymous part of your above view i.e. the
> "general stuff" but will not cache the "private" part of the view.
> BUT, since your view requires login, @cache_page will cache nothing in
> this case or more accurately, the "general stuff" is never going to be
> executed because anonymous users will be redirected to the login page
> by your @login_required decorator.
>
> You can always use the low-level caching API if you want finder
> control over what gets logged in.
>
> > Also, does anyone know of a simple way to tell when stuff is served
> > from cache and not, when you're testing on your production server?
>
> U... don't test on your production server :)
>
> If you use memcached, you can run it in verbose non-daemon mode with "-
> vv" (leave out the -d setting so it runs in your terminal in the
> foreground). That will show you cache hits when you browse to a
> cachable view.
>
> Don't forget to set memcached back to daemon/background mode with the
> verbosity turned off after you're done.
>
> -RD
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Caching and logged-in users

[Håkan W]

Hi all,

I'm a bit confused about the caching. I've started using per-view
caching with the @cache_page decorator.

Now, if I add this to pages that return private content to logged-in
users, will it do the right thing and not show information for one
logged-in user to another? And it must not show logged-in content to
non-logged in users of course.

Example:

@cache_page(3 * 60)
@login_required
def view(request):
   if request.user.is_authenticated():
  # show something that is "private" to this user...
   else:
  # show general stuff, for all non-logged in users

Also, does anyone know of a simple way to tell when stuff is served
from cache and not, when you're testing on your production server?

Thanks in advance!
Håkan

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Don't mix *args and **kwargs in call to reverse()!

[Håkan W]

On 1 Sep, 15:47, Adrián Ribao <[EMAIL PROTECTED]> wrote:
> I'll write an example of the problem. All my urls are prepared
> following the best SEO rules, so in many places I have urls like:
> (r'^(.*)-f(?P\d+)\.html$','view_photo')
>
> this would make the url:
> my-photo-f2.html
>
> I get the url using:
> reverse('app.views.view_photo', args=[slugify(photo.title),],
> kwargs={'id':id} )
> (Note: I don't want to use a slug field.)
>
> Now this won't work. Well, IMHO this is a bug, I don't see the point.
> Besides this makes rev:8760 backwards incompatible and it wasn't
> suppose to.

I just hit this too. There seems to be no information or hint in the
docs about this (neither in the docs about reverse or permalink), from
what I can find...

/Håkan
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---