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

[alej0]

self.object is None because you the workflow is

def form_valid(self, form):
self.object = form.save(commit=False)
self.object.user = self.request.user
self.object.save()
super(CreateCampaignView, self).form_valid(form) # that does the 
redirect

actually it's not necesary to neme it self.object but is a good practice, 
is how other class-based generic views work

self.object is None because you are usin a CreateView, so there is no 
object to work with until you save the form and get the corresponding 
instance.

-- 
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/-/KuS19bSiqMIJ.
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

[Juergen Schackmann]

you made my day, working exactly like expected.  :-)
thanks a lot

-- 
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/-/RUSugDsY9K0J.
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

[Alasdair Nicol]

On 11/01/12 20:54, Juergen Schackmann wrote:

if is use this code, as proposed by russ:
def form_valid(self, form):
self.object.user = ... (something meaningful.. e.g., 
self.request.user)

return super(CreateCampaignView, self).form_valid(form)

i get the error 'NoneType' object has no attribute 'user'. and 
actually, by looking at the source code, that is exactly what is 
supposed to happen in a create view: self.object is set to None, as 
you can see in BaseCreateView


def post(self, request, *args, **kwargs):
self.object = None
return super(BaseCreateView, self).post(request, *args, **kwargs)

am i the only one having this problem? any help is highly appreciated.
thanks
juergen
--
I agree that it looks like self.object is None, so you can't set 
self.object.user as Russ wrote.


How about the following:

def form_valid(self, form):
form.instance.user = request.user
return super(CreateCampaignView, self).form_valid(form)

I haven't had a chance to test the code. I hope that it works, or at 
least leads you in the right direction!


Regards,
Alasdair

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

--
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 
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

[Juergen Schackmann]

I am trying to do the same as described in previous example:
I have a model with a foreign key field to User and in the view I want to 
populate the the field from request.user. 

And when doing it exactly the way as Russ proposed, I get the described 
error.

-- 
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/-/_YvDz1bT9SkJ.
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

[Andres Reyes]

What are you triying to achieve?

2012/1/12 Juergen Schackmann :
> can really no one help? i am really stuck here at the moment
>
> --
> 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/-/RYLQqxJE7HYJ.
>
> 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.



-- 
Andrés Reyes Monge
armo...@gmail.com
+(505)-8873-7217

-- 
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 
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

[Juergen Schackmann]

can really no one help? i am really stuck here at the moment

-- 
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/-/RYLQqxJE7HYJ.
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

[Juergen Schackmann]

if is use this code, as proposed by russ:
def form_valid(self, form):
self.object.user = ... (something meaningful.. e.g., 
self.request.user)
return super(CreateCampaignView, self).form_valid(form)

i get the error 'NoneType' object has no attribute 'user'. and actually, by 
looking at the source code, that is exactly what is supposed to happen in a 
create view: self.object is set to None, as you can see in BaseCreateView

def post(self, request, *args, **kwargs):
self.object = None
return super(BaseCreateView, self).post(request, *args, **kwargs)

am i the only one having this problem? any help is highly appreciated. 
thanks
juergen

-- 
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/-/QD32CnKdQmsJ.
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

[br]

While this doesn't contribute an answer to your question, I must say
that name "class-based generic views" is a bit misleading . . .
implying that these class-based views are for doing things you want to
do that follow a strictly set pattern out of the box (i.e, listviews,
detailviews, create views, etc.), but that you'll have to use
something else (i.e., function based views) if you are defining your
own views.  However, this is not the case at all.  We wanted to switch
all our views to class-based, and have had great success with writing
our own class-based views by extending built-in view and mixin
classes.  Basically, most of our own views extend the generic
TemplateView and we add in our own Mixins or add functionality to the
overridden class methods. Some of our views extend other generic view
classes. As the documentation gets updated and edited, this paradigm
probably ought to be explained, because for a while I just figured
that i still had to still use function views if I wanted to do
anything custom, beyond what the generic views provide in and of
themselves.  They're a different beast but can be much more DRY and
add some OO awesomeness to your code once you get your head around
them.  For now, I'd recommend looking at the source code to see which
functions you can override, its pretty straightforward.

Ben

On Jul 16, 12:26 pm, Paul Walsh  wrote:
> 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 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.

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

[Venkatraman S]

The below email contents can go into the django wiki? Explained in a lucid
manner.
Actually, it would be awesome, if someone from this group can volunteer to
extract useful
text explanations from this ML and put in the wiki.

I would have done it, but i lost my password, and i dont see a 'forgot
password' link in the wiki ;)

On Sat, Jul 16, 2011 at 7:58 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Fri, Jul 15, 2011 at 5:18 PM, Paul Walsh  wrote:
> > 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.
>
> This is admittedly a big problem with the class-based generic views.
> As the person responsible for committing them, I can only offer my
> humble apologies for their current state.
>
> > 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.
>
> Some might, and they would be correct :-)
>
> This isn't a legacy issue at all -- Forms and Views solve different
> problems.
>
> The View is solving the problem of "how do I handle this request and
> convert it into a response?". The Form is solving the problem of "How
> do I convert the POST data in this request into a model object (or a
> change to a model object)?".
>
> Very roughly, a view is doing the following:
>
>  1. View gets a request
>  2. View works out whether this is a GET or a POST
>  3. If its a POST, View asks the Form to turn the Post into a model change
>  4. Form returns success or failure
>  5. View responds to the success or failure of the Form.
>  6. View returns a response.
>
> The functionality of the Form is a complete subset of the
> functionality of the View -- and for this reason, it's a completely
> interchangable internal component.
>
> Now, in simple situations, it's possible for a View to guess all the
> defaults for the form -- all it needs to know is that you're dealing
> with a Foo model, and it can construct a default Foo ModelForm.
> However, if you have more sophisticated form requirements, you're
> going to need a customized Form.
>
> We *could* have implemented this by exposing all the options of
> ModelForm on the View class; but in order to keep everything clean, we
> kept the ModelForm isolated, and provided the View with a way to
> specify which Form class it's going to use.
>
> So - to cover your use case of excluding fields, you define a
> ModelForm that excludes the fields, then let the CreateView know the
> form you want to use:
>
> class ModelForm(forms.ModelForm):
> class Meta:
>model = Campaign
>exclude = ('user', 'name', 'content_inlined')
>
> class CreateCampaignView(CreateView):
>form_class = CampaignForm
> template_name = "forms/create.html"
>
> I'm guessing when you say "fix a values for a field", you mean setting
> the values of user, name and content_inlined before you save the new
> Campaign instance; to do this, you need to inject some extra code into
> the form processing logic of the form:
>
> class CreateCampaignView(CreateView):
>form_class = CampaignForm
> template_name = "forms/create.html
>
> def form_valid(self, form):
>self.object.user = ... (something meaningful.. e.g.,
> self.request.user)
>return super(CreateCampaignView, self).form_valid(form)
>
> This overrides the default behavior when the form is valid, and sets
> the extra values. The super() implementation of form_valid() will then
> save the instance.
>
> For the record, this could also be done by overriding the save()
> method on the ModelForm -- however, if you do that, you lose the
> request object, which you will need if you're trying to set the
> instance values to something that is request-sensitive.
>
> I hope I've provided some helpful clarification here.
>
> Yours,
> Russ Magee %-)
>
> --
> 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
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
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 
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

[Russell Keith-Magee]

On Fri, Jul 15, 2011 at 5:18 PM, Paul Walsh  wrote:
> 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.

This is admittedly a big problem with the class-based generic views.
As the person responsible for committing them, I can only offer my
humble apologies for their current state.

> 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.

Some might, and they would be correct :-)

This isn't a legacy issue at all -- Forms and Views solve different problems.

The View is solving the problem of "how do I handle this request and
convert it into a response?". The Form is solving the problem of "How
do I convert the POST data in this request into a model object (or a
change to a model object)?".

Very roughly, a view is doing the following:

 1. View gets a request
 2. View works out whether this is a GET or a POST
 3. If its a POST, View asks the Form to turn the Post into a model change
 4. Form returns success or failure
 5. View responds to the success or failure of the Form.
 6. View returns a response.

The functionality of the Form is a complete subset of the
functionality of the View -- and for this reason, it's a completely
interchangable internal component.

Now, in simple situations, it's possible for a View to guess all the
defaults for the form -- all it needs to know is that you're dealing
with a Foo model, and it can construct a default Foo ModelForm.
However, if you have more sophisticated form requirements, you're
going to need a customized Form.

We *could* have implemented this by exposing all the options of
ModelForm on the View class; but in order to keep everything clean, we
kept the ModelForm isolated, and provided the View with a way to
specify which Form class it's going to use.

So - to cover your use case of excluding fields, you define a
ModelForm that excludes the fields, then let the CreateView know the
form you want to use:

class ModelForm(forms.ModelForm):
class Meta:
model = Campaign
exclude = ('user', 'name', 'content_inlined')

class CreateCampaignView(CreateView):
form_class = CampaignForm
template_name = "forms/create.html"

I'm guessing when you say "fix a values for a field", you mean setting
the values of user, name and content_inlined before you save the new
Campaign instance; to do this, you need to inject some extra code into
the form processing logic of the form:

class CreateCampaignView(CreateView):
form_class = CampaignForm
template_name = "forms/create.html

def form_valid(self, form):
self.object.user = ... (something meaningful.. e.g., self.request.user)
return super(CreateCampaignView, self).form_valid(form)

This overrides the default behavior when the form is valid, and sets
the extra values. The super() implementation of form_valid() will then
save the instance.

For the record, this could also be done by overriding the save()
method on the ModelForm -- however, if you do that, you lose the
request object, which you will need if you're trying to set the
instance values to something that is request-sensitive.

I hope I've provided some helpful clarification here.

Yours,
Russ Magee %-)

-- 
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 
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

[Andre Terra]

On Fri, Jul 15, 2011 at 7:37 AM, Kenneth Gonsalves
wrote:

>
> caveat - I have never used generic views, class based or otherwise, but
> I was under the impression that if one wants customised forms or views,
> generic is not the way to go.
>
>
These views are classes and they exist precisely so that the code can stay
DRY through specific classes (e.g. MyModelCreateView) that subclass more
generic classes (e.g. MyBaseCreateView) all the way up to the tools django
provides (e.g. CreateView).


Cheers,
André

-- 
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 
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

[Andre Terra]

Paul,

Your form logic will go on your Form (or ModelForm) definition, not on the
view. As the docs [1] say, CreateView is a combination of ModelFormMixin and
ProcessFormView. Please read the docs on those two mixins to understand what
methods your CampaignCreate class can override, but do move the form logic
(i.e. field excluding, validation, etc) to a custom form.

Try something like (the following code hasn't been tested):

# views.py
class CampaignCreate(CreateView):
template_name = "forms/create.html"
form_class = CampaignForm


# forms.py
class CampaingForm(forms.ModelForm)
class Meta:
model = Campaign
exclude = ('user', 'name', 'content_inlined')


Hope that helps!


Cheers,
André


[1]
https://docs.djangoproject.com/en/dev/ref/class-based-views/#django.views.generic.edit.CreateView



On Fri, Jul 15, 2011 at 6:18 AM, Paul Walsh  wrote:

> 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.
>

-- 
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 
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

[Michał Sawicz]

Dnia 2011-07-15, pią o godzinie 16:07 +0530, Kenneth Gonsalves pisze:
> caveat - I have never used generic views, class based or otherwise,
> but
> I was under the impression that if one wants customised forms or
> views,
> generic is not the way to go. 

Why not? The model edit views use the ModelFormMixin, which has a
get_form_class that can be overriden [1] to taste. You can simply get
the form from super().get_form_class and put it through
modelform_factory [2] again to only get the form for the fields you
want.

The classy generic views are really flexible like that. Sadly docs
aren't that great, so reading the code is probably best to get the hang
of it.

[1]
https://code.djangoproject.com/browser/django/trunk/django/views/generic/edit.py#L66
[2]
https://code.djangoproject.com/browser/django/trunk/django/forms/models.py#L370

Cheers
-- 
Michał (Saviq) Sawicz 


signature.asc
Description: This is a digitally signed message part

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

[Venkatraman S]

Class based views reduce the amount of code written, but i am yet to get a
grasp of it(need more experimentation).
Somehow, i prefer plain 'old' way of methods in views.py which respond to
different urls - it gives me better control and is easily to maintain.

-V

-- 
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 
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

[Kenneth Gonsalves]

On Fri, 2011-07-15 at 02:18 -0700, Paul Walsh wrote:
> 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. 

caveat - I have never used generic views, class based or otherwise, but
I was under the impression that if one wants customised forms or views,
generic is not the way to go.
-- 
regards
KG
http://lawgon.livejournal.com
Coimbatore LUG rox
http://ilugcbe.techstud.org/

-- 
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 
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.