Can Django Sub Views be displayed on a Single Web Page

Using Django Getting Started
1

I have been thinking, is possible to have a view and have sub views off it, so that more than one view can be displayed on a single web page ?

What I am trying to do, is to have a Django reference section similar to what W3Schools Django References has.

I have Links to different reference sections (eg Template Tags Reference, Filter Reference etc) on my main home page, as can be seen below.

Django Refs on Home Page
Django Refs on Home Page1440×900 105 KB

This post does not allow me to show another screenshot, but when Template Tag Ref Page Link is clicked, it is meant to display results of all template tags on a /template/ route.
At the moment to keep it working I have shown autoescape off and this is what gets displayed on localhost template/ route below.
I have not been able to get autoescape on displayed below this example, because it has same view.

Django Template Tag Reference

autoescape Template Tag

Autoescape Off

Hello my World!

Check out views.py to see what the heading variable looks like

I have paths setup in urls.py, like this

# Add Routes for Django References Section
    # Template Tag Reference 
    path('template/', views.template, name='template'),
    
    # Filter Reference
    path('filter/', views.filter, name='filter'),
    
    # Field Lookups Reference
    path('field/', views.field, name='field'),

This a Template Page view I have setup in my views.py

# Django References Section (57 to 59)

# Django Template Tag Reference 57 within Django References Section

# Using Keyword Autoescape
# Autoescape Off
#def template_autoescape_off(request):
def template(request):
  template = loader.get_template('template_tag_ref.html')
  context = {
    'heading': 'Hello <i>my</i> World!',
  }
  return HttpResponse(template.render(context, request))

Note: I was trying to use def template_autoescape_off(request): as a sub view, but because that did not work, I have commented it out.

I have also commented out template view for autoescape on as shown in code below, because it did not work with same template view.

# Autoescape On
#def template(request):
  #template = loader.get_template('template_tag_ref.html')
  #context = {
    #'heading': 'Hello <i>my</i> World!',
  #}
  #return HttpResponse(template.render(context, request))

I thought that having all tag references displayed on one page, even though it is long, would cut down on having heaps of routes.

I am also thinking on my localhost home page, if you click on Template Tag Reference and it takes you to localhost /template/ route, all Links could be displayed for each of the tags.

This would be similar to what W3Schools has, but a lot of routes would be needed like /ref_tags_autoescape/ etc and some of these references have more than one example, so they would need more than one view in the page.

I am trying to get some advice on the best way to approach this, so that it works efficiently for me, thanks.

2

The effect that you want to achieve can be done, yes. But not the way you’re thinking of doing it.

To directly answer your question, no. You don’t organize your code such that you’re trying to call multiple views for a page.

You want to change your mindset and your mental perspective for this.

Looking at the fundamentals:

  • A URL calls a view.

  • A view retrieves data to create a dict called a context

    • There are modules known as context processors that are called during the rendering process to add additional data to the context. These context processors are called during every template being rendered and are useful for adding data that needs to be supplied for every page.

  • The view calls a rendering function (e.g. render) with a template name and the context.

  • The rendering function converts that template to an HTML page.

    • The template being rendered can extend a parent template. (That parent template itself could extend yet another template.)
    • The template being rendered can also include other templates. (Those templates being included can likewise include more templates.)

So, in the general case, when you want to add something like a menu to every page, you would write a context processor to add the data for the menu to the context.

You would then add the template code to render that menu to your base template.

It can get more sophisticated than that. Since the context processor receives the original request, it can customize the context data being returned based upon the user making the request. This allows you to customize a menu based upon a user’s permissions.

3

Hi Ken

Thanks for the reply

I am just trying to get an understanding on how to do this with a context processor you have mentioned.
It seems to me that this context processor you mentioned can be used for handling several pages with similar layout.

I have been thinking about the best way I can do this Django Reference Section that Django Template Tags Reference has.

I think for the different sections like Template Tag Reference, Filter Reference and Field Lookups Reference, when you click on them the best way to have this should be to display Links for each of the Tags eg autoescape etc.
This is because when you click that link you can look at each individual tag eg Autoescape, separately rather than have a whole heap of tags on the one page with a template/ route, like I mentioned before.

I am trying to get my head around this.
It seems like all these tag pages for example autoescape Template Tag, Block Template Tag etc can have a parent template for the layout and use a child template as well.

Template Tag Reference page has a template/ route
and a tag found from clicking on a link eg autoescape tag can have a ref_tags_autoescape/ route that is controlled by a context processor, so you do not have to create a whole heap of separate routes.
Need to have some way of controlling these routes for each of the tags for Template Tag Reference, Filter Reference and Field Lookups Reference Sections.

I am going away on holiday in a weeks time, but just want to trying get as good of an understanding on this before I go.

4

Hi Ken

I am not sure how a context processor would work with a situation like mine.
How would a context processor be put in place to make it work similar to what W3Schools Django References section have.

I have noticed that the Template Tags Reference has a List of Tag followed by Description and Filter and Field Looks up both have Keyword and Description

Could a Base (Parent) Template be used to handle displaying of these pages and child templates for specific ones like Field Lookups for example.

Is this how this should work ?

I am not sure how a context processor would handle that ?

Need top get an understanding on how this should work thanks Robert.

5

I think there are at least two and possibly three different topics / issues here that are starting to get mixed together.

I’d like to try to separate them a bit to avoid confusion.

First, Context processors

Whenever you render a page, you’re passing a “context” to the rendering engine. Typically, your view creates the context for that view.

However, it’s common to want to have some additional data on every page.

That is the issue that context processors handle. It is code that gets executed whenever a template is being rendered, to modify the context. That means that every page being rendered will have this additional data in it, and that data is available to the template to be rendered.

A common use for a context processor is for your site menu, if that menu needs to be different based upon some criteria such as the user requesting the page. You want that menu displayed on every page, but the menu data needs to be customized for the user. Instead of calling your menu builder in every view, you call it in a context processor.

However, don’t think of a context processor as having anything to do with the layout. The data provided by the context processor can be used in any (every) template.

Second, template structure.

In the simple common case, your template for a page will extend a base template. Review the section on Template Inheritance. Your base template provides the basic layout for the page, your view’s template fills in the blocks.

Third, the include tag.

This really is a separate concept from template inheritance. It is a way for you to “refactor out” common blocks of html into separate files for use in multiple locations, or to parameterize their use.
(Pay particular attention to the Note box in that section of the docs.)

Final thoughts:

I don’t know if you’re coming to Django from a different framework, but I know many people (myself included) who initially struggled with really understanding the Django template architecture. Some frameworks work by associating blocks on a page with functions in code. Assembling a page then becomes an issue of identifying the blocks on that page, causing the corresponding code for those blocks to be called.

In that sense, it’s the page template that drives the structure of the page.

With Django, it’s the opposite. It’s the view here that drives the page. The view executes some code to create a context and renders a template using that context. Everything is driven and controlled by the view. The template is just some data used along the way to help create HTML.

That’s what you really want to work on wrapping your head around.