Re: So has Instagram...

On Monday, April 9, 2012 10:03:57 PM UTC-7, diogobaeder wrote: > > ... just been acquired by Facebook? And it uses Django? > > Indeed. We can only hope that Instagram will stay on Django under Facebook's care, though I won't be surprised if it's eventually subsumed into their PHP soup. But

Re: Admin site: Appropriateness of HTTP 500 when using non-allowed query strings

I agree with this. HTTP 500 error should not occur due to users attempting to subvert the system somehow. HTTP 500 errors should only be returned when an unhandled exception occurs (which shouldn't happen). Cheers. Tai. On Tuesday, 10 April 2012 21:34:07 UTC+10, 3point2 wrote: > > The admin

Re: auth.user refactor: the profile aproach

Tai, I think you are overestimating the importance of a "pluggable" user model. If 100 apps all try to add fields to the User model then of course bloat and performance issues and field name conflicts will be a problem. But I don't think that will happen. There are very good reasons for an app

Re: auth.user refactor: the profile aproach

On Tue, Apr 10, 2012 at 11:58 PM, Tom Evans wrote: > On Tue, Apr 10, 2012 at 3:13 PM, Ian Lewis wrote: > > Hi, > > > > I'm not getting why you *have* to add fields to the User model to store > data > > pertaining to the user. There is nothing in the

Re: auth.user refactor: the profile aproach

Sorry I was mentioning that in agreement with documenting this. I had even toyed with the idea of making the default template provide a project level user model by default (to cement the fact that it's project concern not a app concern) but that is most likely more trouble than it's worth.

Re: auth.user refactor: the profile aproach

Sure. But will how will users be guided to making that distinction when developing their pluggable apps? I haven't seen anything that would prevent developers from doing this, and if the admin itself does it, isn't that a green light for everyone to do it? Another problem with pluggable apps

Re: auth.user refactor: the profile aproach

I think swappable user models should be used as a replacement for get_profile() not per app profiles. It should be used for generic-esque data about a User. e.g. Email, phone number, name, etc. It should not be used for app specific data about a user, e.g. Default Gallery, Notification

Re: auth.user refactor: the profile aproach

Alex, I think the problem with this aspect of your proposal is that it signals a green light for other pluggable apps to follow Django's lead and provide mixing which must be added to their `User` model in order to use the pluggable app, instead of creating a profile model for their pluggable

Re: auth.user refactor: the profile aproach

Tom, I proposed mixins to solve the specific problem: there is an app that needs a specific contract from a model it wants to authenticate or otherwise interact with, how can we make it easy for developers to implement that contract? Most apps don't actually need that much though. There are a

Re: auth.user refactor: the profile aproach

Hi Tom, The best rounded description with pros and cons is Solution 2a on https://code.djangoproject.com/wiki/ContribAuthImprovements You are correct that I am primarily thinking of pluggable authentication when I think of this new user model. The reason is that there is nothing stopping you

Re: Complex aggregate and expression composition.

> I took a quick look at your patch. I don't have more time now, so just > some quick comments: > [...] I think the approach you have taken is correct in general. I would > encourage to check > if you can somewhat easily incorporate the conditional aggregate support > (#11305) > into the

Re: auth.user refactor: the profile aproach

Hello! The page you linked, Tom, concludes with this line: "Discussion on django-developers suggests that complete consensus is unlikely; Currently awaiting BDFL mandate." Since we have the BDFL mandate, shouldn't we update the page?

Re: auth.user refactor: the profile aproach

On Tue, Apr 10, 2012 at 3:13 PM, Ian Lewis wrote: > Hi, > > I'm not getting why you *have* to add fields to the User model to store data > pertaining to the user. There is nothing in the proposal for pluggable user > models that says you can never have a seperate model with a

Re: auth.user refactor: the profile aproach

Hi, I'm not getting why you *have* to add fields to the User model to store data pertaining to the user. There is nothing in the proposal for pluggable user models that says you can never have a seperate model with a foreign key to the user model. It just means that you can define your user model

Awkwardness of overriding View.dispatch for method-agnostic request-handling

Hi all, [I think this has been mentioned on django-developers before, but I can't find it. If this would be better as an RFE in a ticket, shout at me and I'll raise it there.] In a couple of our projects we have various views on resources differentiated by some aspect of the request (query

Admin site: Appropriateness of HTTP 500 when using non-allowed query strings

The admin site allows the use of certain query strings to filter change list pages. The syntax follows queryset field lookups, for example http://mysite.com/admin/myapp/mymodel/?field__exact=test. Lookups that are not specified on the ModelAdmin's list_filter option raise a SuspiciousOperation

Re: auth.user refactor: the profile aproach

Tom, Thanks for raising those issues. I would just like to add that I hope to see fields currently in `User` that are required by the admin (is_staff, etc.), moved to an admin profile model, and not simply made available through mixins that are still required by every `User` model that gets

Re: auth.user refactor: the profile aproach

On Fri, Apr 6, 2012 at 7:31 PM, Alex Ogier wrote: > Tai, read https://gist.github.com/2289395 for a summary of many reasons why > I think profiles are a bad idea, and unifying multiple profiles is an even > worse idea. > > Best, > Alex Ogier Hi Alex Is