Web Frameworks - nested templates
Archive - Originally posted on "The Horse's Mouth" - 2013-02-22 09:41:42 - Graham EllisThere are times when an inversion of long-accepted logic makes sense. I've been working in a many-floored office block in Salford this week, with a bank of lifts to travel between floors. Rather than press a button for your floor once you're in the lift, you press a button in the lift lobby when you want to ride, and the computer system assigns you to a particular lift which pops up on an LCD display. Result? - each departing lift calls at a limited number of floors only, and passengers are balanced out between them. It's unconventional, it's the opposite of what you would expect, but it actually (in my limited experience of a few uses) seems to work and make sense. I must add a caveat that I find it disconcerting to not have any buttons for floor numbers in the lift ... I can't change my mind once I've started my journey, unless someone else has already selected and been allocated to my lift for the new floor, and I can't decide quite as easily as I might in the past to pass on a busy lift / one that's got someone I don't want to travel with in it already.
Web Frameworks use an inverted logic for their view templates too.
If you're going to render a template ("view results from doing something as a web page"), that obvious thing is to say "I want this global template that relates to the company site as a whole. Into it fill this subtemplate, which represents my particular application, and (perhaps) into that fill in a sub-subtemplate for the particular result set". It sounds obvious, but it's not the best way to do it ...
In my application, I'm simply going to say "I want my results to be in this subsubtemplate". Included within the subsubtemplate is a directive which says "I fit into the following subtemplate", and in that subtemplate is a directive which says "I fit into the following main template". Parameters specified within the subsubtemplate (known as methods / really macros) can be used as a way of passing elements such as titles up from the lower level to upper levels, and the upper levels each include some sort of statement / marker which says "this is where the lower level stuff is put". There's a big advantage in doing it this way - all the apprication controller needs to do is to specify a single template for where it's to put its results, and that template then sorts out the rest of the view. Which may be a common and shared view across many applications and no longer needs to be a concern of the controller, nor to be duplicated.
C and C++ programmers may be familiar with the make utility on Unix and Linux boxes. The same inverted logic applies here too. The user says "I want to make a program called jelly" let us say. Make sees that jelly depends on jelly.o ... and that jelly.o depends on jelly.c - working up the tree. It then compiles jelly.c into jelly.o, links jelly.o with other stuff to make the final jelly executable, and the whole thing's completed with a passage up the tree to work out what needs to be done, followed by a passage down the tree to actually do it.
Django, Rails, Mason and Zend Frameworks all use this approach, counter-intuitive though it is. And Ant, Maven and other build systems use it too. It's actually right, proper and clever ... just a bit odd for the newcomer to get his head around!
Django - low level
{% extends "staff/mybasepage.html" %}defines a series of blocks which are called into the upper level via:
{% block pagetitle %} Page Name {% endblock %}replacing "Page Name" with the subview content. See [here]
Rails - low level:
(Looks by folder and file naming convention to the "layouts" folder)
upper level:
<%= yield %>this is where the lower level should be cut in. See [here]