Hi,
i just starting to use CBVs in django
and i try to implement something like that:
from django.views.generic import DetailView
from .models import Product, ProductOpinion
from .forms import OpinionForm
class OpinionListMixin(object):
queryset = ProductOpinion.objects.all().order_by('-date')
def get_context_data(self, **kwargs):
context = {
'opinion_list': self.queryset
}
context.update(kwargs)
return super(OpinionListMixin, self).get_context_data(**context)
class OpinionFormMixin(object):
form_class = OpinionForm
def get_context_data(self, **kwargs):
context = {
'form': self.form_class
}
context.update(kwargs)
return super(OpinionFormMixin, self).get_context_data(**context)
def form_valid(self, form):
return super(OpinionFormMixin, self).form_valid(form)
class ProductDetailsView(OpinionListMixin, OpinionFormMixin, DetailView):
queryset = Product.objects.filter(status=True)
template_name = "product.html"
context_object_name = "product"
but how to filter productopinions in OpinionListMixin by product_id
and how to set product_id in OpinionFormMixin
and do i need to set now success_url?
W dniu środa, 29 sierpnia 2012 23:24:55 UTC+2 użytkownik Melvyn Sopacua
napisał:
>
> On 29-8-2012 18:46, Rainy wrote:
> > On Aug 29, 3:10 am, Melvyn Sopacua <m.r.sopa...@gmail.com> wrote:
> >> On 29-8-2012 4:44, Rainy wrote:
> >>
> >>> When I use CBVs, I nearly always end up needing to mix different types
> in
> >>> the same view, e.g. detail view and list view, list view and modelform
> >>> view, etc. I really like CBVs but I feel this is the one shortcoming
> that I
> >>> constantly run into that makes CBVs much less flexible and helpful
> than
> >>> they could be.
> >>
> >> What are your real world cases for this? If you combine several models
> >> to make up a page, you should consider writing your own mixins that
> >> inherit only from ContextMixin and implement get_context_data() to add
> >> the extra information.
>
> <snip example>
>
> > I will give some examples at the end of the message, but first I want
> > to expand a bit on this idea.
> >
> > Let's say you have a detail CBV, FooView(DetailView): model = Foo ;
> > and a list view, BarView(ListView): model = Bar .
> >
> > Now, combining different types of views is an extremely common case
> > and you might say that the cases when you don't need to do that are
> > usually so simple that existing GCBVs already handle them perfectly.
>
> The list and detail view don't bite each other in many aspects. However,
> as you will list in examples below, you usually don't have just one list
> view per page. See below.
>
> > I don't see any apparent reason why the two examples above can't
> > be combined exactly in the same way you inherit each separate view:
> > FooBarView(DetailView, ListView): detail_model=Foo; list_model=Bar.
>
> Because how would you declare a second list model? And how would you
> pick these up? Aside from making the routing through the model
> difficult, this will also be a declaration nightmare.
>
> > As a bonus, you don't have to decide which mixin to use and when
> > overriding methods, you will know which instance variable and method
> > handles detail and list objects.
>
> Except when you need more than one list or detail or both.
>
> > Here are a few examples where it would be useful, and I can find many
> > more in my projects:
> >
> > - blog post: 3 CBVs: post, list of comments, comment form
> > - search: FormView, ListView
> > - photo album: detail view for album, listview of images
> >
> > I know each of these cases can be handled with current GCBVs but
> > with a lot more effort and in a more verbose and error-prone way
> > than what I'm proposing.
>
> I don't see that:
> class BlogView(CommentListMixin, CommentFormMixin, DetailView) :
> model = BlogPosts
>
> versus:
> class BlogView(DetailView, ListView, CreateView) :
> detail_model = BlogPost
> list_model = Comments
> form_model = Comments
>
> I find the second version harder to read, more verbose to type and when
> you want to support multiple models you will have to support some sort
> of sequence or mapping. Not to mention how you'd handle template-coder
> friendly names through context_object_name and similar.
>
> Yes, the first version requires more work to code the mixins, but I
> don't find them harder to debug either. In fact, pretty much only one
> point where things can go wrong: get_context_data().
>
> I can see your point and some of my issues with it may well be personal
> preference, but I'm not sure if the Generic CBV's are a good base for
> what you ask of them. I'm currently working on a RelatedModelMixin and
> subsequently a FormsetMixin and I already feel like I'm coloring outside
> the lines.
> It's made me consider the fact that function based views are more
> natural. A view really is a process where you hand it some info and it
> returns what you asked for. It's less natural to think of it as a
> collection of parts (objects) in a machine that work together to produce
> your result.
>
> However, once you know the order in which things are flowing through the
> magic machine, debugging them isn't hard and things make a lot of sense
> so I think part of the blame here is in the documentation which is in
> fact improving a lot.
>
> Last but not least, I think you should start writing if you feel
> confident it can be done and is an improvement. It's the best way to
> find out if your ideas can work or if another approach should be sought.
>
> --
> Melvyn Sopacua
>
--
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/-/G7XaJZM0MhoJ.
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.
