> > > still, it's not exactly clear to me why the admin does not work the same
> > as
> > > other templates.
>
> > The Admin is not a template. So, I don't know what you mean by that.
>
> admin is not using templates? well, i did not check the implementation.
Sorry, if I wasn't clear. The admin does use templates but it's much
more than that (that's why I said that the Admin is not a template).
Moreover, the Admin change-list and all its other templates have to be
dynamic because they don't know beforehand what fields each model is
going to have and which of those are going to be displayed via
list_display.
So, as I explained above, there's no way for the admin to guess what
you want it to do with related many-valued fields like Post.comments
in your case. So, it chokes when you try to do such a thing.
>
> The whole point is that in your own template, you decide whether you
>
> > want to display the count of comments or a list of comments or the
> > names of the commenters, and so on. How would the Admin know what you
> > want if you were allowed to put "comments" in the list_display? One
> > user may want the count, another may want something else. That's why
> > the Admin supports calling methods in your model class. And through
> > such methods you are able to display your comments field exactly the
> > way you want.
>
> agree, though it would make sense to me to return the RelatedManager
> instance, just like in the templates.
What would that give you? In the change list you would just see the
class name of the RelatedManager. Is that what you mean?
Remember that in your own templates, you don't just say:
{{ post.comments }}
Instead you either loop over comments or do a length filter on them,
etc. In other words, you are actively making the decision on what you
want to do with that related manager instance.
Also, there's one other important difference: when you loop over
post.comments in your template, you are causing a DB query that brings
in the comments of that single post instance. If an Admin were to do
that, it would have to issue an extra query for each row it is going
to display in the change-list screen.
All this is documented in the second bullet here:
http://www.djangoproject.com/documentation/model-api/#list-display
-Rajesh
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
