Re: Please help me with CBV template_name behaviour.

Dear James & All,

I installed the Django Debug Toolbar and here is what it says when i navigate to 'http://127.0.0.1:8000/contacts/psearchc/last_name/contains/d/'

Template path

1. C:\Users\joeco\djtut\mysite\templates

Template

contacts/contact_list.html

C:\\Users\\joeco\\djtut\\mysite\\templates\\contacts\\contact_list.html

Context:

{'False': False, 'None': None, 'True': True}
{'DEFAULT_MESSAGE_LEVELS': {'DEBUG': 10,
                            'ERROR': 40,
                            'INFO': 20,
                            'SUCCESS': 25,
                            'WARNING': 30},
 'csrf_token': <SimpleLazyObject: '8EMBPVWQwGxM4RqYdoUYNbLZcdGX3Wyo'>,
 'debug': True,
 'messages': <django.contrib.messages.storage.fallback.FallbackStorage object at 0x000001E614D9C8D0>,
 'perms': <django.contrib.auth.context_processors.PermWrapper object at 0x000001E614D91940>,
 'request': '<<request>>',
 'sql_queries': <function debug.<locals>.<lambda> at 0x000001E614DA7A60>,
 'user': <SimpleLazyObject: <User: joeco>>}
{}
{'contact_list': '<<queryset of contacts.Contact>>',
 'is_paginated': False,
 'object_list': '<<queryset of contacts.Contact>>',
 'page_obj': None,
 'paginator': None,
 'view': <contacts.views.ParametricSearchCRUDListContactView object at 0x000001E614D9C278>}

Context processors

django.template.context_processors.csrf

{'csrf_token': <SimpleLazyObject: '8EMBPVWQwGxM4RqYdoUYNbLZcdGX3Wyo'>}

django.template.context_processors.debug

{'sql_queries': <function debug.<locals>.<lambda> at 0x000001E614DA7A60>, 'debug': True}

django.template.context_processors.request

{'request': <WSGIRequest: GET '/contacts/psearchc/last_name/contains/d/'>}

django.contrib.auth.context_processors.auth

{'perms': <django.contrib.auth.context_processors.PermWrapper object at 0x000001E614D91940>, 'user': <SimpleLazyObject: <User: joeco>>}

django.contrib.messages.context_processors.messages

{'DEFAULT_MESSAGE_LEVELS': {'INFO': 20, 'WARNING': 30, 'DEBUG': 10, 'ERROR': 40, 'SUCCESS': 25}, 'messages': <django.contrib.messages.storage.fallback.FallbackStorage object at 0x000001E614D9C8D0>}

Again, i am EXPECTING the view to use the

CRUD Template == 'contacts/crudlist.htm';

NOT the Plain TEMPLATE == 'contacts/contact_list.html'

OK EVERYONE, I APOLOGIZE. I HAD A SPELLING MISTAKE.

'contacts/crudlist.htm'

SHOULD HAVE BEEN

'contacts/crudlist.html'

All WORKS NOW.

THANKS for the help.


At least i found out about the Django Debug Toolbar.

Sorry again. Thanks AGAIN.

Love and peace,

Joe

On Monday, June 20, 2016 at 9:18:44 AM UTC-7, JoeCodeswell wrote:

Dear James,

Thanks for your reply.

1. I'll investigate using the "Django debug toolbar".
2. re: "extraneous classes":  I was trying to make a point of how to construct the second-2 classes from the first-2. The second-2 classes (CRUD classes) are a text copy of the first-2 with the difference being that the second-2 have their names changed, in the appropriate 2 places & (I THOUGHT) they point to A DIFFERENT Crud Template ('contacts/crudlist.htm'). The Crud Template IS NOT USED FOR RENDERING. INSTEAD the Template mentioned in the first-2 classes is used.
3. re: "template inheritance structure". Any Django Docs on this subject?

I'll investigate the Debug Toolbar & see what it tells me.

Again, THANKS, BIG TIME, James.

Love and peace,

Joe

On Saturday, June 18, 2016 at 10:52:46 PM UTC-7, James Schneider wrote:

> I EXPECT the Views with CRUD in their names (CRUD Views) to behave THE SAME AS the others EXCEPT items are listed with read, update & delete links, because that is how `contacts/crudlist.htm` displays them.
>
> THE PROBLEM IS that the CRUD Views display the items using the Plain Template (contacts/contact_list.html) NOT the CRUD Template ('contacts/crudlist.htm')
>

The Django debug toolbar can likely illuminate the problem here, or at least provide a direction. You would need to verify the template(s) that have been rendered as part of your view call, and that they're actually doing what you think they're doing.

It's a bit hard to follow your code, as you include extraneous classes that don't appear to be relevant to the problem (no inheritance, no indication they've been triggered, etc.). With that being said, your output from the view appears to be correct and shows a different (and correct) template_name for each view. I might be missing something though, and admittedly I'm responding on my phone.

My assumption at this point would be that the templates are rendered correctly by Django (correctly meaning 'as configured'), and that the issue actually lies within your template inheritance structure (if any). Again, the debug toolbar will walk you through that.

-James

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/42fa0c5f-b6a9-4d79-9da4-f3414e4ea1f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.