Re: ForbiddenMixin for Django?

in subclasses is a good to have. On Feb 3, 6:15 pm, Lukasz Rekucki <lreku...@gmail.com> wrote: > On 3 February 2011 16:09, Jari Pennanen <jari.penna...@gmail.com> wrote: > If they're not decorators, then that's even worse, 'cause you need to > duplicate all existing permissio

Re: ForbiddenMixin for Django?

On Feb 3, 2:16 pm, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Thu, Feb 3, 2011 at 4:47 PM, Jari Pennanen <jari.penna...@gmail.com> wrote: > The pair of Ls in my email address aren't just there for show. Russell. Two > Ls. I'm terribly sorry, that was uninte

Re: ForbiddenMixin for Django?

"Meh - this seems like reinventing a syntactic wheel to me. Python 2.6 has class decorators." - Russel Why to use decorators? They cannot be overridden neatly in subclasses, see my above gist about this subclassing. -- You received this message because you are subscribed to the Google Groups

Re: ForbiddenMixin for Django?

Here is now subclassed from View, and checked that overriding works: https://gist.github.com/809208 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe

Re: ForbiddenMixin for Django?

I noticed that it is safer to subclass ForbiddenMixin from View because of MRO: https://gist.github.com/808516 If it is subclassed from View, then above would throw error and one could not even define them in wrong order: AuthedViewSecond(View, ForbiddenMixin): -- You received this message

ForbiddenMixin for Django?

I opened up a ticket http://code.djangoproject.com/ticket/15215 in order to make the class based view permission checking easier. I don't know do other think that they need to be easier to check, but I think following API would be simple: class ProtectedView(TemplateView, ForbiddenMixin):

Re: One Django instance, hundreds of websites

On Jan 31, 8:27 pm, Carl Meyer wrote: > On Jan 31, 1:49 am, Xavier Ordoquy wrote: > > > The thread is pretty long because there are also 2 threads in one: > >  - one for simply changing the site_id per request > >  - one for changing the all setting

Re: One Django instance, hundreds of websites

On Jan 31, 8:30 am, James Hancock wrote: > This post is getting pretty long. But I had a simple Django fix that would > make it work a lot easier for me, and might help others. (I say this because > of how I implemented it, I am working with about 60 different sites and it >

Re: One Django instance, hundreds of websites

Notice that I never suggested *django* to implement thread local hack, it just allowes me to continue. The thread local hack is just that hack, it hides the real problem for now since Django does not support the stuff I need it to. Settings object should be considered mainly read-only, if the

Re: One Django instance, hundreds of websites

In above I have error: authbackend.save(session, user) -> bool authbackend.load(session) -> user object should be: authbackend.save(request, user) -> bool authbackend.load(request) -> user object Since getting site id from request is the thing I need to do and save it to session. --

Re: One Django instance, hundreds of websites

With globals: No patches to Django required. Flatpages, media urls, media roots can be customed by request and works without single problem. Mostly because settings are used like settings.SITE_ID etc. and not like getattr(settings, 'SITE_ID') in apps. If Django ever is patched to work without

Re: One Django instance, hundreds of websites

On Jan 30, 7:20 am, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Sat, Jan 29, 2011 at 8:55 PM, Jari Pennanen <jari.penna...@gmail.com> > wrote: > If an engineer came to their supervisor with a problem and said "I'm > going to fix this problem with a

Re: One Django instance, hundreds of websites

Hi! I suggest you to look on to this _patch_setattr I cooked. I noticed that it is also necessary to patch the __setattr__ of the settings object in order to allow changes to the settings.SITE_ID again. Following test would fail after TLSProperty: settings.SITE_ID = 42 assert settings.SITE_ID

Re: One Django instance, hundreds of websites

have to be aware is that if this make_tls_property is not done early enough my apps must not rely on this method: SETTING = getattr(settings, 'MYAPP_SETTING', 'default') especially if the use SITE_ID, MEDIA_URL or MEDIA_ROOT. On Jan 29, 2:55 pm, Jari Pennanen <jari.penna...@gmail.com>

Re: One Django instance, hundreds of websites

Certainly something new for me. That does look like a rather cool. Essentially if that works one could save even the request object to thread "global" and it would be accessible anywhere. It would solve many problems, such as django's authentication middleware's shortcoming where it does not

Re: One Django instance, hundreds of websites

Graham is correct. I pointed out this in my reply to reviewboard method which works just like Jjdelc proposed, and that is incorrect way. So simply put: Changing settings object in middelwares is WRONG. If one changes the settings object before or after request, it will be in intermediate state

Re: One Django instance, hundreds of websites

On Jan 26, 6:56 pm, FeatherDark wrote: > Greetings huge django developer list, > I just wanted to mention, this method totally works for me, I call it > "Skinning" > > In the templates folder I have a file called "base.html' > Inside that file is only 1 line: > {% extends

Re: One Django instance, hundreds of websites

On Jan 26, 5:20 pm, Xavier Ordoquy wrote: > Given the title, I would feel bad for the sysadmin if there was hundreds of > setting files with just the site id within ;) Ha, single file per site :) I would change to that any day. The current system in place is following:

Re: One Django instance, hundreds of websites

For the project which I plan to use this is such that all sites could share same INSTALLED_APPS, but it would be truly awesome if full settings were possible for each site. On Jan 26, 5:10 pm, Lorenzo Gil Sanchez wrote: > I suggest to have a look to

Re: contrib.sites and multitenancy

This is the stuff I've come up on first try few days ago: Here is my current cache implementation: https://gist.github.com/795135 And here is my middleware: https://gist.github.com/795138 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: contrib.sites and multitenancy

Hi! I've started another thread since I was oblivious about this one. One thing I noticed in my early experimentation is that caching Site objects is a bit of waste. I don't know what is the overhead for caching Site objects compared to just IDs but I suppose when we get to hunderds of sites and

One Django instance, hundreds of websites

Hi! I'm on a monumental task here, I've decided to get one Django instance running hundreds of websites. I've run in to couple of shortcomings with django: 1. Global SITE_ID does not work since some requests belong to different site. I've created middleware that adds request.site_id based on

Re: Class based generic views in 1.3?

On 13 touko, 03:14, fitzgen wrote: > * How to deal with state and self. I have written an instantiator that > wraps the view class and instantiates a new instance of the class for What about class method "instantiator"? It does have one extra nicety, it does not need to be

Re: Class based generic views in 1.3?

On 11 touko, 03:37, Russell Keith-Magee wrote: > show us the code!. > > [1] > http://github.com/jacobian/django/tree/class-based-generic-views/django/views/generic2 Yes, well. I have been in slight assumption that the above code is the one that will be merged. Though

Class based generic views in 1.3?

I've been trying to figure out the state of class based generic views without success. (Though syndication views seems to be class based now at least.) If I figured out correctly the class based generic views does not land on 1.2, so I was wondering are they planned to 1.3? Those are rather

Status of branch soc2009/http-wsgi-improvements? (and ticket 2131)

Hi! I was wondering what is the status of branch branches/soc2009/http- wsgi-improvements ( http://github.com/django/django/tree/soc2009/http-wsgi-improvements )? I'm personally interested one bug it fixes, mainly ticket #2131 ( http://code.djangoproject.com/ticket/2131 ) The branch seems to be

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

I read from "1.2 beta" thread that this might make it to the 1.2 beta of Django, any status on that? Is someone trying to commit the patches? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: select_related to work with backward relationships?

On Mar 24, 3:08 am, Malcolm Tredinnick wrote: > Seriously, if we documented everything that wasn't possible with Django, > the documentation would be a couple of million words long. There's > nothing that says select_related() does work with reverse relations and > if

Re: select_related to work with backward relationships?

Found out that it doesn't work. I think this should be documented that backwards relationships does *not* work in select_related, since I see no reason why it couldn't work, it might be tricky to implement, but I think it should be doable. If it were documented, someone might get idea to

select_related to work with backward relationships?

Hello! class City(models.Model): # ... class Person(models.Model): # ... hometown = models.ForeignKey(City, null=True, blank=True) class Book(models.Model): # ... author = models.ForeignKey(Person) # Can I cache Persons and Books too when getting City? After all there is

WTForm should be inbuilt to Django, and make admin & others use it.

WTForm is simple implementation built on top of existing (new)forms to help create fieldsets, and by judging django snippets alone one can see it's a huge hole in Django. Everyone has wondered why the heck doing those fieldsets is such a pain when in admin it is super easy, and it turns out the

Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)

Modularity of edit inline? Any better? Currently: models.ForeignKey(Other, edit_inline=models.TABULAR, parameters...) obiviously is a big waste of OO abilities, instead something like, the OO way: models.ForeignKey(Other, edit_inline=models.TabularInline(parameters)) were much better. (I know