Re: Class-Based Generic Views (CreateView) - field exclusions and defaults
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
