Why Template Tags Instead of Python?

Django Internals
1

Why are the dynamic elements within templates supported by template tags instead of allowing normal Python to be used?

2

The intent is to keep processing out of the templates - and I consider that to be an ideal objective.

I’ve worked with too many Java/Spring based systems with logic scattered between servlet classes and JSPs to want to allow anything other than display logic to be present in the templating language.

Having said that, Django also supports the use of other templating languages. Someone could design and implement a template language allowing that to be done. (I just wouldn’t use it.)

1 Like
3

Ken, I really appreciate this response. Thank you for providing a complete rational based on first hand experience. I cannot tell you how frustrating it has been over the years to be lectured at by people who are parroting a litany based on what they had told to them, without grounding the explanation in the brass tacks that are reality we work with. I have read countless times about the virtues of separating code from html, but never has the accompanying explanation made sense, especially considering the insanity built into a lot of templating solutions promoted in those lectures. The result is I never could understand the real reason for having a template language that is different from the server side scripting language. In contrast, the Django templates I have seen so far align with the explanation of why a separate template language is used.

Now, I am struggling to implement in Django a job currently running in a php script/hack of mine. The script loads a file/directory list from the server’s file system, then displays the list as hyerlinks for navigating, with controls on what is shown and which files and directories have links. The final result looks like this:

image
image1044Ă—343 79.2 KB

A live example is available at this link.

I don’t yet understand how to break up this process with Django to clean it up and learn how to develop in Django. I have another thread started on this question.

4

I have seen your other post, but since I’ve never used Django CMS, I’m not sure I can provide an appropriate or helpful response.

However, since we’re on the topic here, I’ll toss out some general thoughts -

  • The general flow of events is that
    • A request is made to your site
    • Django examines the request to find a view to handle that request
    • Django executes the view
    • The view gets all the data that will be needed on the page to be displayed, organizing it in a dictionary referred to in Django as the context
    • The view invokes a rendering engine, passing to it a template and the context. The rendering engine uses the context to populate the template and generate HTML, returning it to the view
    • The view builds an HttpResponse object containing the rendered HTML back to Django, which then returns that to the requesting browser.
      (There are some “shortcut” functions that consolidate some of these steps, but they’re still being done - it’s just that they’re not directly visible to you.)
  • So if I were doing this, I’d likely take this approach as what seems to me to be the quickest / easiest to get started.
    1. Figure out what data is needed for the template to generate the desired output - what will probably turn out to be some type of nested data structure, perhaps a list of dicts.
    2. Identify what parameters will be needed for this. (Perhaps a path? Directory name?)
    3. Write my view to create that data - realizing that I may need to make adjustments to what I had come up with in step 1.
    4. Create my template to display the data.

(I tend to not worry about the template until after I have figured out what data is going to be available to the template and know how it’s going to be structured.)

How much of this is applicable to a Django CMS environment - I have no idea. But hopefully it’ll give you some thoughts on the topic.