Re: Django-Registration/Custom Authentication Issue

[Paul Walsh]

These are the changes you'll have to make to django-registration, if you 
are using AUTH_USER_MODEL in django 1.5 and inheriting from AbstractUser:

https://bitbucket.org/prjts/django-registration/commits/ba31fc3053bfca7eb7a19d912882e50e295adc55



On Friday, 19 April 2013 11:52:55 UTC+3, Paul Walsh wrote:
>
> James Bennet says above that it is compatible, but the latest 
> django-registration code is not compatible with custom user models.
>
> RegistrationProfile, for example, still refers directly to User, whereas 
> the new custom user implementation in Django 1.5 require this to be changed 
> in order to work when AUTH_USER_MODEL is actually being used.
>
> See the docs here 
> https://docs.djangoproject.com/en/dev/topics/auth/customizing/#referencing-the-user-model
>
> Seeing as in Django, we can't override fields when we subclass models, we 
> cannot "subclass the provided stuff" in this case. Of course, we can 
> override forms and views.
>
> In a current django app I am working on, and indeed in every Django app I 
> have worked on, the I was happy with the default user model, and extended 
> it with a profile that included language settings, for example - I didn't 
> replace functionality.
>
> The Django 1.5 docs refer explicitly to my use case:
>
>
> https://docs.djangoproject.com/en/dev/topics/auth/customizing/#extending-django-s-default-user
>
> But, django-registration does not work with this use case.
>
>
>
>
> On Wednesday, 17 April 2013 10:51:44 UTC+3, James Bennett wrote:
>>
>> Current hg tip is actually 1.5-compatible, in the sense that if you want 
>> to use your own User model, you just subclass the provided stuff and plug 
>> in your model, either importing directly or using the helper function in 
>> Django 1.5.
>>
>> django-registration does not do this itself because
>>
>> 1. Using Django 1.5's helpers requires either extra complication of the 
>> imports, or a break with Django 1.4 compatibility, and
>> 2. If you're using a custom User model, you will by definition be wanting 
>> to subclass and override the default fields, validation logic, etc., since 
>> only a User model identical to django.contrib.auth.models.User works with 
>> the defaults.
>>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django-Registration/Custom Authentication Issue

[Paul Walsh]

James Bennet says above that it is compatible, but the latest 
django-registration code is not compatible with custom user models.

RegistrationProfile, for example, still refers directly to User, whereas 
the new custom user implementation in Django 1.5 require this to be changed 
in order to work when AUTH_USER_MODEL is actually being used.

See the docs 
here 
https://docs.djangoproject.com/en/dev/topics/auth/customizing/#referencing-the-user-model

Seeing as in Django, we can't override fields when we subclass models, we 
cannot "subclass the provided stuff" in this case. Of course, we can 
override forms and views.

In a current django app I am working on, and indeed in every Django app I 
have worked on, the I was happy with the default user model, and extended 
it with a profile that included language settings, for example - I didn't 
replace functionality.

The Django 1.5 docs refer explicitly to my use case:

https://docs.djangoproject.com/en/dev/topics/auth/customizing/#extending-django-s-default-user

But, django-registration does not work with this use case.




On Wednesday, 17 April 2013 10:51:44 UTC+3, James Bennett wrote:
>
> Current hg tip is actually 1.5-compatible, in the sense that if you want 
> to use your own User model, you just subclass the provided stuff and plug 
> in your model, either importing directly or using the helper function in 
> Django 1.5.
>
> django-registration does not do this itself because
>
> 1. Using Django 1.5's helpers requires either extra complication of the 
> imports, or a break with Django 1.4 compatibility, and
> 2. If you're using a custom User model, you will by definition be wanting 
> to subclass and override the default fields, validation logic, etc., since 
> only a User model identical to django.contrib.auth.models.User works with 
> the defaults.
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Class-based FormView Contact Form

[Paul Walsh]

Hi Russ,

Thanks for the input. I am actually looking to use FormView as opposed to 
UpdateView or CreateView because I am not working with model data at all: I 
want to create a simple contact form, and send the data of the form to a 
recipient via email - I don't want to write anything to the db at all. I am 
pretty new to Django so maybe this is obvious to some. Anyway, the way I 
understand your answer it is basically to do with model data. 

I'll dig into the source code.

thx

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/zSYRSHSDqF0J.
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: Class-based FormView Contact Form

[Paul Walsh]

Anyone?

I really want to use class-based views, but it is hard with so much missing 
in terms of examples/tutorials.

thx.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/E5tqbVq8HNsJ.
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.

Class-based FormView Contact Form

[Paul Walsh]

I want to make a contact form using the class-based FormView. How do I pass the 
recipient email? 

Let's say I want a pre-defined recipient, and also the option for the sender of 
the form to receive a copy.

I can do this with a function view but I'd like to use the new class-based 
generic views.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/CryrcLwPXH0J.
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: Django 1.3 CreateView/ModelForm and dynamic filtering of fields

[Paul Walsh]

hmm. Still stuck on this. I have tried a range of solutions, but none work 
for me with 1.3 class-based views.

Can anyone help?
thx,

paul.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/mlKncEnymlMJ.
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: Django 1.3 CreateView/ModelForm and dynamic filtering of fields

[Paul Walsh]

can anyone help with this?

thx.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/oB-B4Y8NHVQJ.
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.

Django 1.3 CreateView/ModelForm and dynamic filtering of fields

[Paul Walsh]

I am trying to filter a field on a ModelForm. I am subclassing the generic 
CreateView for my view. 

I found many references to my problem on the web, but the solutions do not 
seem to work (for me at least) with Django 1.3's class-based views.

Specifically, my users need to add Subscribers, and each Subscriber has a 
m2m field that assigns him/her to a SubscriberList. When the form to create 
a subscriber loads for a given user, I need to options in subscriber_list to 
be filtered for that user's lists only. 

Here are my models:

#models.py

class Subscriber(models.Model):

user = models.ForeignKey(User)
subscriber_list = models.ManyToManyField('SubscriberList')

class SubscriberList(models.Model):

user = models.ForeignKey(User)
name = models.CharField(max_length=70)

Here is my view:

#views.py

class SubscriberCreateView(AuthCreateView):
model = Subscriber
template_name = "forms/app.html"
form_class = SubscriberForm
success_url = "/app/subscribers/"
 def form_valid(self, form):
self.object = form.save(commit=False)
self.object.user = self.request.user
return super(SubscriberCreateView, self).form_valid(form) 



Here is my original form for adding a Subscriber, with no filter:

#forms.py

class SubscriberForm(ModelForm):
 class Meta:
model = Subscriber
exclude = ('user', 'facebook_id', 'twitter_id')

Here is my modified form, attempting to filter, but doesn't work:

#forms.py

class SubscriberForm(ModelForm):
 class Meta:
model = Subscriber
exclude = ('user', 'facebook_id', 'twitter_id')
 def __init__(self, user, **kwargs):
super(SubscriberForm, self).__init__(**kwargs)
self.fields['subscriber_list'].queryset = 
SubscriberList.objects.filter(user=user)
If I change this modified form as so:

def __init__(self, user=None, **kwargs)

It works - It brings me NO subscriber lists. But any way I try to pass the 
request user, for eg., def __init__(self, user=request.user, **kwargs), I 
invariably get a a name "request" or name "self" not defined error.

So, how can I modify my code to filter subscriber_list by the request.user, 
and still use Django 1.3's CreateView.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/fD7CoioGtgIJ.
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: Class-Based Generic Views (CreateView) - field exclusions and defaults

[Paul Walsh]

Hi Russ,

Wow - your response is *exactly* what I needed - thanks a great deal :)

As you mention in there, *because* CreateView gets me so far without the 
Form class (it builds me a form based on the model I declare), I was exactly 
looking to do other "ModelForm" stuff at the CreateView level.

Now it is clear to me what I need to do. Thanks for your class-based generic 
views contribution, and I really hope someone will have the chance to do 
more docs and examples for class-based views. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/XuIVKvgwZ-0J.
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.

Class-Based Generic Views (CreateView) - field exclusions and defaults

[Paul Walsh]

I am pretty new to Django - new enough to be developing my first Django app 
on 1.3. So, I am basing all my work on class-based generic views, and have 
never used the older generic view functions.

A problem I have is the lack of examples and documentation on the new 
class-based generic views.

My current problem is that I am trying to build some forms based on models. 
I am not using Django Forms (ModelForm), but rather CreateView. CreateView 
gets me almost there, but I can't find any documentation on (1) how to 
exclude fields, and (2) how to fix a value for a field.

My class is like so:

class CreateCampaignView(CreateView):
model = Campaign
template_name = "forms/create.html"

I tried exclude from ModelForms, like this:

class CreateCampaignView(UserAccountCreateView):
model = Campaign
template_name = "forms/create.html"
exclude = ('user', 'name', 'content_inlined')

and that doesn't work. Is there another way to exclude fields using 
CreateView?

and, one of my excluded fields, "user", also needs to get the value of 
self.request.user

I tried again here to apply the docs from ModelForms here for CreateView, 
but it doesn't work.


Some might suggest I use Django Forms - it is a reasonable suggestion of 
course. But, being new, I don't have any "view legacy" and I just like the 
idea of working with class-based generic views where possible.

thanks.


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/g4ADYoJAbE0J.
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.