Re: Glad site is being brought back.

[Daniel Sokolowski]

Super legendary, thank you for your efforts.

-Original Message- 
From: Bruno Renié

Sent: Wednesday, June 06, 2012 10:47 AM
To: django-developers@googlegroups.com
Subject: Re: Glad site is being brought back.

On Wed, May 30, 2012 at 10:30 PM, Daniel Sokolowski
 wrote:
Please disregard this message, it was meant as a reply to a thread not a 
new

thread.

-Original Message- From: Daniel Sokolowski
Sent: Wednesday, May 30, 2012 12:35 PM
To: Django developers
Subject: Glad site is being brought back.


I was just about to post a public message to Simon Willison urging him
to shut it down or fix the site when I found this thread.

I wish to say thank you and am very grateful that you are fixing and
bringing the service back.

On unrelated note would it be possible to change my username on the
site from: djangopeople.net/danols/ to djangopeople.net/
danielsokolowski/ ?


As announced on the Django weblog, people.djangoproject.com is live :)

The code currently lives on my github account [0]. Feel free to submit
issues and pull requests if you have ideas for improvements on the
site. I'll look at renaming usernames, in the meantime if you need
anything custom just get in touch privately.

Bruno

[0] https://github.com/brutasse/djangopeople

--
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 from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Daniel Sokolowski
Web Engineer
Danols Web Engineering
http://webdesign.danols.com/
Office: 613-817-6833 


--
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 from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Glad site is being brought back.

[Bruno Renié]

On Wed, May 30, 2012 at 10:30 PM, Daniel Sokolowski
 wrote:
> Please disregard this message, it was meant as a reply to a thread not a new
> thread.
>
> -Original Message- From: Daniel Sokolowski
> Sent: Wednesday, May 30, 2012 12:35 PM
> To: Django developers
> Subject: Glad site is being brought back.
>
>
> I was just about to post a public message to Simon Willison urging him
> to shut it down or fix the site when I found this thread.
>
> I wish to say thank you and am very grateful that you are fixing and
> bringing the service back.
>
> On unrelated note would it be possible to change my username on the
> site from: djangopeople.net/danols/ to djangopeople.net/
> danielsokolowski/ ?

As announced on the Django weblog, people.djangoproject.com is live :)

The code currently lives on my github account [0]. Feel free to submit
issues and pull requests if you have ideas for improvements on the
site. I'll look at renaming usernames, in the meantime if you need
anything custom just get in touch privately.

Bruno

[0] https://github.com/brutasse/djangopeople

-- 
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 from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Draft branch: Swappable User models in contrib.auth

[Andrew Ingram]

On 4 June 2012 16:12, Russell Keith-Magee  wrote:
>  * The swapping mechanic is set up using a new Meta option on models
> called 'swappable' that defines the setting where an alternate model
> can be defined. Technically, the swappable option *could* be used for
> any model; however, I'm not proposing that we actually document this.
> I've implemented it as a generic approach purely to make the internals
> cleaner -- mostly to avoid needing to make references to auth.User in
> the model syncdb code, and to make testing possible (i.e., we can do
> validation tests on a dummy 'swappable' model, rather than trying to
> munge a validation test for auth.User specifically).

I like the idea of a 'swappable' option, but I can see some potential
issues with the implementation. I'm one of the developers of Oscar
(https://github.com/tangentlabs/django-oscar/) and providing a clean
method to for overriding models has been a major pain point. One of
our key requirements is that any model in Oscar may be overridden, to
that end every model has both abstract and concrete versions (much
like your implementation of AbstractBaseUser and User).

Our current way of handling overrides is for every reference to a
model in Oscar to use get_model rather than the explicit classname.
But this does end up causing some ugly things like this:

from oscar.apps.catalogue.abstract_models import AbstractProduct

class Product(AbstractProduct):
# stuff

from oscar.apps.catalogue.models import *


Issues:
1) The override model HAS to have the same name as the default model,
otherwise get_model('catalogue', 'Product') won't work.
2) We have to import all the remaining default models after we declare
our overrides. But this only works because Django's model metaclass
prevents the default Product replacing the one we've just defined. I
don't like this because it's a little bit magic.
3) You have to remove Oscar's version of the app from INSTALLED_APPS
and replace it with your own. Actually, technically you don't. If you
leave Oscar's app installed but put your own one ('foo.catalogue') in
front of it, you can even get rid of the nasty import * thing - but
again, more magic. (Aside: you can actually use this approach already
to override Django's User model, because the metaclass means any
references to Django's User will be replaced with references to your
own. )

I had investigated using a class decorator to handle overrides:

@replace_model('catalogue.Product')
class MyProduct(AbstractProduct):
# foo

But this got seriously complicated because the metaclass modifies the
class before the decorator can be applied, so I was looking into ways
to sever all the ties with the app cache before I went insane and gave
up.

Back to my main points... Your swappable option would solve quite a
lot, in the case of the User model it's ideal. But I'm concerned that
if people start using it more widely we'd end up having dozens of new
settings that would get quite silly in the case of a large project
like Oscar. I think it's important that overrides can be defined in
the settings file, but I'd also like to see it possible at model
definition time, either using a decorator (like above) or a Meta
option like 'replaces'. The risk, of course, is that it means any
third-party app could override any other model without you necessarily
being aware of it, not sure how this would be mitigated.

If I've not made much sense let me know, I've always found it hard to
articulate on this particular topic.


Regards,
Andrew Ingram

-- 
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 from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ModelForm enforces its version of save_m2m

[is_null]

Thanks for answering. It's "funny code" but it works indeed.

Thanks again

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/2_4X_NFZmP8J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django's CVB - Roadmap?

[Xavier Ordoquy]

Hi,

I also had a couple of issues with Django's generic CBV.
My feeling is it raises a lot of frustration because it feels like there isn't 
much missing.
I've been playing with a few solutions to work around that.

I started a small proof of concept on chaining GCBV and a few other goodies.
I'm a bit reluctant to speak about it because *I'm not happy* with the way it 
currently is now.
The general idea was to be able to go as far as possible for newcomers without 
modifications.
To achieve that result, I took example on what forms and models already and 
used the same thing to chain mixins.

It currently what it looks like is.

1) define the mixins

class ProjectMixin(ObjectMixin):
model = Project
pk_url_kwarg = 'project_id'

def get_queryset(self):
return Project.objects.filter(members=self.request.user.id)

class BugMixin(ObjectMixin):
model = Bug
pk_url_kwarg = 'bug_id'

def get_queryset(self):
return = Bug.objects.filter(project=self.project)


2) define the views

class ProjectView(View):
project = ProjectMixin(default_mode='detail')


class BugView(ProjectView):
projects = ProjectMixin(mode='list')
bug = BugMixin(default_mode='detail')


3) define the urls

urlpatterns = patterns('',
url(r'^projects/$',
ProjectView.as_view(mode='list'),
name='projects'),
url(r'^projects/new/$',
ProjectView.as_view(mode='new'),
name='new-project'),


)


A few things to notice.
View can inherit from the others.
Objects are "namespaces" in the view. See I get project (a single object) and 
projects (list of projects the user is member of) in the BugView.
You define only one view that you can specialize into list, detail, create, 
update, delete (although delete isn't implemented yet).


The current state for that:
- There's no documentation (as I said, I was a bit reluctant to do that mail 
because it is still a bit early)
- I recently switched from reusing the django's generic cbv to duplicating them 
in the code. A few implementation details still need to be cleaned.
- I'm not happy with the way I "specialize" the mixins according to the mode 
they should be in. I'm currently changing the mixin instance's heritage which I 
feel is *not* what I should do. I'll probably try to do something similar to 
what the forms do with BoundField
- I'm not happy with the way the "mode" is set too.
- Paginators have a semi working namespace. They *are* namespaced in the 
template, but aren't for the url part, this is work in progress.

Please keep that in mind if you have a look at the current code.

The "proof of concept" is there:
https://github.com/linovia/django-alternative-views

I wrote a demo project:
https://github.com/linovia/django-alternative-views/tree/master/demo

Tests should cover most (think it was around 90%) of the custom code. Since the 
inclusion of django generic cbv, it has droped but I'll see how I can play 
django's test for that part (not going to rewrite existing tests).


Regards,
Xavier Ordoquy,
Linovia.

-- 
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 from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Draft branch: Swappable User models in contrib.auth

[Russell Keith-Magee]

On Tue, Jun 5, 2012 at 9:00 PM, Anssi Kääriäinen
 wrote:
> Understood & agreed (the "this model is dynamic made explicit" part
> seems really important specifically).
>
> I am afraid of the hard-coding of meta.swappable must be 'SOME_VAR'
> which then references settings.SOME_VAR, and that this is made part of
> the public API by the error messages. I would imagine that after app-
> loading refactor one would make the swappable an app-level constant,
> but the use of settings.AUTH_USER_MODEL directly in the code makes
> this change backwards incompatible. Any chance of making what the
> "swappable" contains more abstract? Something like suggesting making
> foreign keys point to auth_user_ref() instead of
> settings.AUTH_USER_MODEL.
>
> Another idea would be to change the "swappable" to contain a method
> reference, and then hint in the foreign key error message that "point
> to User._meta.swappable() instead". (Or, make that Model property, so
> that you could say to point to User.swapped_by instead, and
> User.swapped_by would contain the real reference by checking where
> User._meta.swappable points to).

I can see the problem you're driving at, but I'm not sure it will
actually be a problem in practice.

Of course, it's impossible to know for sure without knowing the final
App-refactor API, but based on the most recent discussions, the idea
is to define a class that defines the App. I imagine that swappable
models would be a part of this definition -- something like:

auth_app = App(
   …
   swappable_models = {
  'User': 'myauth.MyUser'
   })

The exact syntax may be different, but the point should be clear --
the App provides the point where the substituted User model can be
configured, replacing the need for an AUTH_USER_MODEL setting.

If this is the case, the requirement for "Meta: swappable" reduces
from needing to name a specific setting, to just providing a boolean
that defines the fact that the App is allowed to accept overrides.
Conveniently, 'AUTH_USER_MODEL' (or any other string value) evaluates
as True, so AUTH_USER_MODEL will be a slightly non-sensical value, but
a perfectly legal on. It also means that the app can exist in both
worlds (a settings-overridden model, and an App-defintion overridden
model. There's some prioritisation logic required there, but thats a
relatively minor detail). Long term, the syntax can reduce to 'class
Meta: swappable=True'.

> As for the User model as an ORM object - what lookups can be assumed
> to exist? It seems the only requirement is that it has a numeric
> primary key called 'id', otherwise there isn't anything that can be
> assumed of it?

The short answer is that there aren't any *hard* requirements. The
only time requirements come into the picture is if you want to
minimise the amount of additional code you want to write.

If you want to integrate with a minimum of effort, the only
requirement that exists is that your model must provide a unique
string-based identifier field (e.g. username), a password field, and a
last login timestamp. The latter two you get for free from the
AbstractBaseUser class; the unique identifier field must be provided
as part of your model definition. It doesn't matter what the unique
identifier field is called -- it just needs to exist, and if it's not
called username, you need to define USERNAME_FIELD as a class
attribute. Strictly, the login timestamp isn't required, but it's used
for password reset tokens, so I figured it makes sense to include it
by default.

I've done some further checking, and the primary key restriction I
wrote about previously doesn't actually exist. As long as your primary
key can be stored as a string in the session, the default auth backend
will work.

As your model gets less like the out-of-the-box auth.User model, your
workload increases. Depending on your exact User model, you may need
to define forms to create/update a user, and define a ModelAdmin for
your custom User model. I still need to look into how much of these
forms can be made even easier to reuse.

If your User model requires something more than 1 identifier field
(e.g., username and domain), you're still ok -- you just need to
define your own Authentication forms and auth backend.

So - in summary, it really should be a case of "Any User model will
do"; it's just a matter of how much extra work needs to be done.

However, if your requirement is to work with Admin, there are a couple
more requirements. I *think* the minimum requirement is a definition
for the following:

 * get_full_name
 * get_short_name
 * __unicode__
 * has_perm
 * has_module_perms
 * is_staff
 * is_active

However, I need to do a full audit for this list to make sure I
haven't missed anything. The permissions in particular are
interesting, because they don't need to be "auth.Permission" objects
-- you just need to be able to answer True/False for a string name.
This means you can handle permissions using Django's approach if you