It's an update of snippet [https://djangosnippets.org/snippets/1376/](https://djangosnippets.org/snippets/1376/) to work with Django 1.8. With this piece of code, you can override admin templates without copy or symlink files. Just write your template and extend the target.
Updated a similar snippet by "King" to work with Django 1.6. This is especially useful for overriding the admin templates without having to symlink or copy them into your project. For example {% extends "admin:base.html" %} would extend the admin page base.html.
Simple snippet to show the names of the templates on the page. It's a custom template loader that just prints out the name of the template at the start of the template. To set it up, just place it in a file, for example spy.py. Then edit settings.py and add this to the start of the tuple list for TEMPLATE_LOADERS. TEMPLATE_LOADERS = ( 'appname.spy.load_template_source', 'django.template.loaders.filesystem.Loader', 'django.template.loaders.app_directories.Loader', ) This was useful for me because I'm starting to use a django project that's a big on the big side and I'm trying to do a theme for it. I'm not very familiar with their templates, so these visual cues will help instead of walking through the template code. Hope this is helpful for some one else too.
This is http://djangosnippets.org/snippets/1376/ rewritten as a new class-style Loader, and slightly improved. Allows you to reference templates like this: app_label:some/template/name.html This makes it possible to insert customizations at any point in a template hierarchy. For example, you could replace a block within the base admin template: {% extends "admin:admin/base.html" %} {% block breadcrumbs %}Custom Breadcrumbs-Style{% endblock %}
Loading templates by path app.template_name -> app/templates/template_name.html app.subdir.template_name -> app/templates/subdir/template_name.html Usage: append in settings.TEMPLATE_LOADERS and using render_to('app.index', context)
Ok... this is really a hack. But I love it. I hate setting up all of my test cases into suites, and making sure that I remember to add them each time I add a new python file... annoying! This allows me to have a tests package and then just add python files and packages to that test package (mirroring my app setup). Each of the files are then dynamically imported and every test case is automatically executed. If you don't want one to execute, add it to the ignore list. If you add 'views' to the ignore list, it will ignore all views, otherwise you would have to specify 'package.views' if it is in a package. So... in short this is a bit ghetto, but it saves me a lot of time just setting up all my tests... now I can just write them! Hope it's useful to someone. Greg
You can use this template loader if you want to use template specifically from one app. Useful mainly in overriding admin templates - just make your own `admin/change_form.html` and have it extend `admin:admin/change_form.html` withou creating any symlinking or copying django admin's templates to alternate location. Part of the [ella project](http://www.ellaproject.cz/).
This snippet provides support for dynamically importing templates. This helps you to avoid naming collisions and other problems. The format is as follows: 1. `module.submodule.app:template.html` 2. `module.submodule.app:subfolder/template.html` 3. `module.submodule.app:/subfolder/template.html` Assuming the module is located in '/var/', these would map (respectively) to: 1. `/var/module/submodule/app/templates/template.html` 2. `/var/module/submodule/app/templates/subfolder/template.html` 3. `/var/module/submodule/app/templates/subfolder/template.html` The colon splits the the python module from the template directory, meaning you can import from anything that has a "templates" directory. This helps me to avoid naming collisions by specifying the application I'm referring to, without having to put long paths in my extends and include tags inside other templates. It's also dynamic in that if I move a library outside the old path, it has no effect on the templates. To get this rolling, in your `settings.py` file, add the following:: >TEMPLATE_LOADERS = ( > 'addons.template_loader.load_template_source', # <--- add this > 'django.template.loaders.app_directories.load_template_source', > 'django.template.loaders.filesystem.load_template_source', ># 'django.template.loaders.eggs.load_template_source', >)
This server-side middleware implements some of the functionality in the Yahoo User Interface Loader component. YUI JavaScript and CSS modules requirements can be declared anywhere in the base, inherited or included templates, and the resulting, optimized `<script>` and `<link rel="stylesheet">` tags are inserted at the specified position of the resulting page. Requirements may be specified in multiple locations. This is useful when zero or more components are included in the HTML head section, and inherited and/or included templates require possibly overlapping sets of YUI components in the body across inherited and included templates. All tags are collected in the head section, and duplicate tags are automatically eliminated. The middleware understands component dependencies and ensures that resources are loaded in the right order. It knows about built-in rollup files that ship with YUI. By automatically using rolled-up files, the number of HTTP requests is reduced. The default syntax looks like HTML comments. Markup for the insertion point is replaced with `<script>` and `<link>` tags: <!-- YUI_init --> Component requirements are indicated, possibly in multiple locations, with the `YUI_include` markup. It is removed from the resulting page by the middleware. Example: <!-- YUI_include fonts grids event dragdrop --> Non-minified and compressed versions are requested, respectively, by: <!-- YUI_version raw --> <!-- YUI_version debug --> Example: <html><head> <!-- YUI_init --> <!-- YUI_include dom event --> </head><body> <!-- YUI_include element selector reset fonts base --> </body></html> Renders: <html><head> <link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/2.5.1/build/reset-fonts/reset-fonts.css" /> <link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/2.5.1/build/base/base-min.css" /> <script type="text/javascript" src="http://yui.yahooapis.com/2.5.1/build/yahoo-dom-event/yahoo-dom-event.js"></script> <script type="text/javascript" src="http://yui.yahooapis.com/2.5.1/build/element/element-beta-min.js"></script> <script type="text/javascript" src="http://yui.yahooapis.com/2.5.1/build/selector/selector-beta-min.js"></script> </head><body> </body></html> The markup format can be customized with global Django settings. Example: YUI_INCLUDE_PREFIX_RE = r'{!' YUI_INCLUDE_SUFFIX_RE = r'!}' would change markup to e.g. `{! init !}` and `{! include dom event !}`. The base URL is customized with the `YUI_INCLUDE_BASE` setting, e.g.: YUI_INCLUDE_BASE = 'http://localhost:8000/yui/build/' To remove the XHTML trailing slash from the `<link>` tag, use: YUI_INCLUDE_CSS_TAG = '<link rel="stylesheet" type="text/css" href="%s">' See also the [home page for this module](http://trac.ambitone.com/ambidjangolib/wiki/YUI_include).
One of the things about Django that has always irked me is that there seems to be no standard facility for just loading a page and displaying it, simply. Yes, there is the flatpages module, but it is primarily designed for loading content from a DB. While you specify a custom template and put in junk values for the DB content, it just feels like extra, unnecessary work. Thinking about the problem some more, I borrowed from the idea of flatpages and implemented a view that will load an otherwise unmapped template off the filesystem and render it. This is very useful when converting an existing site over. Just copy your files over. No need to map anything in the URL conf or use the admin to add any flatpage entries. Since it'll render the template, too, you can even use tags and what not, so it need not be a static page.
10 snippets posted so far.