Re: Have get_profile() delegate to one of several profile models depending on type of user
What is the criteria in the User model that gives you users profile model ? If you don't have such a criteria in User's model then you have answered your question, On Jan 28, 9:11 pm, Chris Pratt <[EMAIL PROTECTED]> wrote: > This question has been asked a few times before, but doesn't seem to > be getting any responses. > > I'm working on a project where we have three types of users, each > requiring vastly different profile models. The AUTH_PROFILE_MODULE > setting, obviously, allows only one profile to be specified. > > One response to this question suggested branching from an intermediate > profile model. Thereby, you could call something like: > > request.user.get_profile().get_for_user() > > and it would return the appropriate profile. This seems like a fair > enough approach, but it's a bit kludgy, and certainly doesn't lend > itself towards DRY code that anyone can manipulate. What happens if > someone comes along later and doesn't know they're supposed to tack on > the extra method call? > > It would be easy enough to rewrite the get_profile() method to pull > the right profile and then monkey patch the User model, but this feels > wrong. > > What would be considered best practice here? > > Thanks, > Chris Pratt --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Templates, filesystem, caching?
Template loader returns a source code for template, not parsed Template object. So no big gain here :( > In the early days of Django, Adrian, Simon et al looked at that. It > wasn't worth it, since, in the grand scheme of things, template caching > and checking the cache wasn't that much faster than loading and parsing, > particularly in the overall response time of a request (of which > template parsing is a relatively small component). Adding complexity for > minimal gain isn't usually a good idea. Unless this is a universal win, > it would be better to write it as a third-party template loader. It's > fairly easy to write a template loader that takes another template > loader as a parameter and just wraps caching around it and that keeps > the core code cleaner. > > Regards, > Malcolm > > -- > The cost of feathers has risen; even down is > up!http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Templates, filesystem, caching?
Hi. In production environment IMHO it really doesn't matter because you have to restart server anytime you change the python code. If you treat templates as code that really doesn't matter. We have about 50 production servers and we restart a farm every time we change the code. We do it progressively so users don't feel the difference. We do it 2-3 times a day. So I think this is not a huge issue when you have to restart server every time you change templates. On Dec 23, 4:55 pm, Eratothene <[EMAIL PROTECTED]> wrote: > Hi forgems! > > Your snippet requires to restart django each time the templates have > changed. Did you try to add checking of template file modification > date in order automatically invalidate cache? What it is performance > of such implementation? Adding this kind of mechanism will increase > performace without any loss of functionality. Such implemention will > definitely be included into django base. Please, try it out. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Templates, filesystem, caching?
Hi, i'm author of the snippet http://www.djangosnippets.org/snippets/507/. I have used simple dictionary because pickling and unpickling values from the cache are IMHO to expensive and don't give a big speed boost over parsing. Also if you use memcache or filesystem backend for caching (pretty standard thing in production environment) you don't really have a speed boost because you have to use IO to get template (+pickle). In my tests with pretty simple templates, lighttpd and fastcgi django process, with my setup i've got from ~400 rps to almost 900 rps. You could just create a blank app in your project and paste my snippet in __init__.py file of that app, and put that app into your INSTALLED_APPS tuple. Now you can enable and disable template caching with just one line in your settings. On Dec 23, 8:00 am, "Rob Hudson" <[EMAIL PROTECTED]> wrote: > On 12/21/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > In the early days of Django, Adrian, Simon et al looked at that. It > > wasn't worth it, since, in the grand scheme of things, template caching > > and checking the cache wasn't that much faster than loading and parsing, > > particularly in the overall response time of a request (of which > > template parsing is a relatively small component). Adding complexity for > > minimal gain isn't usually a good idea. Unless this is a universal win, > > it would be better to write it as a third-party template loader. It's > > fairly easy to write a template loader that takes another template > > loader as a parameter and just wraps caching around it and that keeps > > the core code cleaner. > > I wonder if the template system has become a bit more complex since > then. I also wonder if whatever tests they used included things like > includes in for loops. I tend to think that the filesystem is slow > and anything to remove FS calls and shove things in memory is a good > thing -- especially something that could potentially be in a for loop. > Obviously there are trade-offs as you mention but the patch didn't > look that complex to me -- actually it was surprisingly straight > forward. > > I've considered applying this patch and testing against a project I'm > working on. Maybe that would help prove to either Django or me that > this is or isn't worth it. > > Thanks, > -Rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
