On Thu, Dec 9, 2010 at 12:42, Luke Plant <l.plant...@cantab.net> wrote:
> Hi,
>
> First, in answer to your question in the title - yes, normally you
> should report bugs like this to Trac, once you are sure you've found a
> bug.
>
>
Then is better, we disscuss if this is really a bug.
> > The problem here is:
> >
> >
> > If i don't set a context_object_name in my app, the method
> > get_context_object_name puts a name based in the verbose_name_plural
> > of my model's name but in the method get_context_data, ithe queryset
> > is set twice, first as 'object_list' and then with the generated name.
> > Querysets being lazy, this is not really a problem in templates, but
> > if I want to serialize that context generated by get_context_data (to
> > create a generic view that outputs results in json), I will load the
> > data twice and that could be a problem.
>
> I don't see anything that makes me think the data will be loaded twice.
> Have you actually seen this happening in practice? Giving a single
> QuerySet object two entries in a dictionary doesn't clone it.
>
>
This are my classes:
class JSONResponseMixin(object):
def render_to_response(self, context):
return self.get_response(self.serialize(context))
def get_response(self, content, **httpresponse_kwargs):
"""
Construct an `HttpResponse` object.
"""
httpresponse_kwargs.update({'mimetype':"application/json",
'content_type':"application/json"})
return HttpResponse(content, **httpresponse_kwargs)
def serialize(self, context):
return json.dumps(self.to_json(context))
def to_json(self, context):
"""
here i intent serialize the context in a generic way just translate
paginators and queryset to dictionaries for the method json.dumps
"""
...
class JSONListView(JSONResponseMixin, BaseListView):
pass #This is similar to the clases in django's code, the BaseListView
is the class in django/views/generic/list.py
This is not generic, is for an app:
class ProductListView(JSONListView):
queryset = Product.objects.all()
this is my urls.py
(r'^test/$', ProductListView.as_view()),
and i get a json like this:
{
- paginator: null
- is_paginated: false
- page_obj: null
- -
products: [ <- here is the queryset serialized
- -
{
- id: "06ceb119-6bb4-47da-b7bc-907ea556978a"
- name: "item 3"
}
- -
{
- id: "2f4e7698-8ee0-4642-920d-81e8422b5dfc"
- name: "item 2"
}
- -
{
- id: "c4ce445f-f38f-4548-8354-1071374dbc3c"
- name: "item 1"
}
]
- -
object_list: [ <- here again
- -
{
- id: "06ceb119-6bb4-47da-b7bc-907ea556978a"
- name: "item 3"
}
- -
{
- id: "2f4e7698-8ee0-4642-920d-81e8422b5dfc"
- name: "item 2"
}
- -
{
- id: "c4ce445f-f38f-4548-8354-1071374dbc3c"
- name: "item 1"
}
]
}
if you read the json, the variable object_list and products are the same
the code that generate both variables is:
if page_size:
paginator, page, queryset, is_paginated =
self.paginate_queryset(queryset, page_size)
context = {
'paginator': paginator,
'page_obj': page,
'is_paginated': is_paginated,
'object_list': queryset <- here
}
else:
context = {
'paginator': None,
'page_obj': None,
'is_paginated': False,
'object_list': queryset <- here
}
context.update(kwargs)
context_object_name = self.get_context_object_name(queryset) <- here
context_object_name is 'products' and i dont tell that to django
if context_object_name is not None:
context[context_object_name] = queryset <- here is set the same
query again, no matters if you put context_object_name or not
I think the right behavior is (and was in old generic views)
if you don't put the name of your queryset this will be object_list and
don't get the name dinamiclly. I mean, if I put a context_object_name in the
class that inherits from ListView or somthing like BaseListView, why anyways
you get a 'objects_list' variable with the same queryset?
> > In the edit,py file (django/views/generic) the
> > class ModelFormMixin inherits from FormMixin and the
> > methods form_invalid from both classes are the same code:
> >
> >
> > return self.render_to_response(self.get_context_data(form=form))
> >
> > I think the method from ModelFormMixin just should call super from
> > FormMixin, like in form_valid, but perhaps this is intentional.
>
> Even better would be to miss out the method altogether. I can't think
> why right now, but it is possible that it is intentional - if so a
> comment to say why would be better.
>
>
> Luke
>
> --
> "My capacity for happiness you could fit into a matchbox without
> taking out the matches first." (Marvin the paranoid android)
>
> Luke Plant || http://lukeplant.me.uk/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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.
