Django tutorial suggests to organize templates like this:
Within the templates directory you have just created, create another directory called polls, and within that create a file called index.html. In other words, your template should be at polls/templates/polls/index.html. Because of how the app_directories template loader works as described above, you can refer to this template within Django simply as polls/index.html.
Tutorial also tells what happens if I just put index.html in polls/templates:
Now we might be able to get away with putting our templates directly in polls/templates (rather than creating another polls subdirectory), but it would actually be a bad idea. Django will choose the first template it finds whose name matches, and if you had a template with the same name in a different application, Django would be unable to distinguish between them. We need to be able to point Django at the right one, and the easiest way to ensure this is by namespacing them. That is, by putting those templates inside another directory named for the application itself.
My assumption was that as long as I'm creating an isolated application, it's templates are also isolated from other apps without any subfolder magic.
Is there another way to namespace, so I can refer to template as index.html without creating duplicated folders?
The way templates are organised in a Django project is very flexible. So there's nothing to stop you ordering the template files however you want, as long as you specify the correct template name in the view. For example, you could use a Class Based View for the list of Polls, specifying the template_name as whatever you like:
# polls/views.py
from django.views.generic import ListView
from .models import Poll
class PollList(ListView):
model = Poll
template_name = 'any/path/you/choose/any_name.html'
Having said that, it's good to create a consistent template structure to keep the code maintainable. I'd recommend at the very least keeping your page-level templates (things which are used to return the whole html page) structured in folders with their relevant app name, and anything you include (snippets included with the {% include %} tag) within includes subfolders, like so:
templates
- base.html
polls
- poll_list.html
includes
- poll_votes.html
Edit:
If you still need namespaces despite this, you could use URL namespaces.
Related
I am learning Django and I programming a CRUD for various objects. Currently I need to generate three templates per object: one for creation, one for update and one for a list. Look at how many templates I got in the picture.
The process is becoming painful.
What I am doing wrong and how to correct it?
Thanks.
From your comment:
The problem is that If I need to make a change, for example, add a new button, I have to make it in all the templates.
That sounds wrong. Either a button belong to one type of thing and then it should only exist in that template, or it should be on every page and then it should be in the base template.
You can make one template with your basic page layout (including such buttons), and have "blocks" in them that are then filled out by each template that extends the base template.
See the Django documentation about template inheritance.
Also, I think that in most cases the "create" and "update" pages are going to be extremely similar; usually they use the same template, one with data already filled in, the other without.
You could have a base template, then a generic list template and a generic edit/create template, with templates for each type of thing extending the list and the edit templates to fill in only the relevant fields.
Also, maybe you use HTML that is close enough to what the Django forms can render themselves. Then as long as you call the edit/create form the same in each of your views (like "form"), the template can just render the form and they can all use the same template.
If you're building a big web-app then this is normal for templates to be more.
Heavy (big) web-app means = more templates + more code + more time + more features
I've been writing my first Django app and hit a problem with using templates.
No matter how I format the url for the template I receive the TemplateDoesNotExist error.
My html is nest in views/ with the core template being views/template.html.
I have tried:
myapp/views/template.html
views/template.html
templates/views/template.html
<full path to app>/<all variations>
None of which can locate the template.
I understand the TEMPLATE_DIRS variable may be set at project level but this is app-specific and the views/ directory is not purely for templates.
I don't think I should add to the url_patterns since the template shouldn't be accessible directly.
I've got this far without them but need to clean up the app.
Any advice?
Edit:
The only line in my controller currently is:
template = loader.get_template("test/templates/test/template.html")
The line has been tested with every variation mentioned above and the one from the first comment.
There are no additional lines added to the urlpatterns, as I understand it adding to here would open access up to the public via url.
it should be:
template = loader.get_template("test/template.html")
It took me forever to find out why a template was not getting overridden, only to find that it seems Django simply does not use the correct precedence in overriding the templates.
The templates I'm trying to change are the ones for changing the user's password, which are loaded for the URL /accounts/password/change.
I have my modified templates in mysite/myapp/templates/registration; the system default templates are at /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/admin/templates/registration. When templates are present in both these directories, Django uses the system (/Library) ones. Huh?
When I remove the templates in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/admin/templates/registration
, the correct ones (i.e. mine, in mysite/myapp/templates/registration) are loaded.
How to fix this issue? That is, how to make Django load my overridden templates without having the delete the original templates found in the /Library?
you have to create an admin directory inside the templates dir in which you set the templates you want to override
In order to override one or more of them, first create an admin directory in your project’s templates directory. This can be any of the directories you specified in TEMPLATE_DIRS.
Read the Django doc here
I have my template folder with all html templates lieing together in the template folder with no directory structure as such.
I decided to arrange them on per app basis, but:
A template with template-tags belong to different apps.
Eg:
Login page(Login app) includes a banner that belongs to UserActivity [User activity app]. So, if I include the login template in login folder in templates, then it will be including stuff across other app's template folder.
How should I structure so that all that referred stays in 1 place organized ?
Feel free to ask for more info.. :)
Organizing your templates in subdirectories is definitely they way to go, but I am not sure if you can really reach the level of separation you are looking for.
If your apps depend on each other you'll always have includes and tags from other apps. So i'd put the templates to the app they belong to.
But maybe the docs about template loaders can help you clarify your structure.
For example the app_directories.Loader
Loads templates from Django apps on the filesystem. For each app in
INSTALLED_APPS, the loader looks for a templates subdirectory. If the
directory exists, Django looks for templates in there.
This means you can store templates with your individual apps. This
also makes it easy to distribute Django apps with default templates.
So you could put app-specific templates in in your app directories and keep your general templates (base.html, etc.) in the top level template dir of your project.
I've been developing in Pylons for a little while now and have recently learned they're merging with another framework to create Pyramid.
I've been looking over example code to see the differences and it's causing a bit of confusion...
For example, Controllers have been replaced by Views. Not a big problem... But what I find interesting is there's no directories for these. It's simply one file: views.py.
How does this new MVC structure work? Do I write all my actions into this one file? That could get rather annoying when I have similarly named actions (multiple indexes, for example) :/
Could you point me in the direction of some good tutorials/documentation on how to use this framework?
Since the various view-related configuration methods (config.add_view, config.add_handler) require you to pass a dotted name as the class or function to be used as a view or handler, you can arrange your code however you like.
For example, if your project package name were myproject and wanted to arrange all your views in a Python subpackage within the myproject package named "views" (see http://docs.python.org/tutorial/modules.html#packages) instead of a single views file, you might:
Create a views directory inside your mypackage package.
Move the existing views.py file to a file inside the new views directory named, say,
blog.py.
Create a file within the new views directory named __init__.py (it can be empty,
this just tells Python that the views directory is a package.
Then change the __init__.py of your myproject project (not the __init__.py you just created in the views directory, the one in its parent directory) from something like:
config.add_handler('myhandler', '/my/handler', handler='mypackage.views.MyHandler')
To:
config.add_handler('myhandler', '/my/handler', handler='mypackage.views.blog.MyHandler')
You can then continue to add files to the views directory, and refer to views or handler classes/functions within those files via the dotted name passed as handler= or view=.
Here is one answer that should be pretty straight forward. This question was asked when Pyramid 1.3 wasn't yet out. So forget about python handlers since the new decorator do a pretty good job now.
But just to start: Pyramid doesn't have any common structure. You could possibly write a whole app in one single file if you wanted. In other words, if you liked how pylons was structured, you can go with it. If you prefer to setup your own structure then go for it.
If your site doesn't need more than one file then...GO FOR IT!!! All you really need is that it works.
I personally have a structure like that
- root
- __init__.py # all setup goes there
- security.py # where functions related to ACL and group_finder
- models.py or models/ # where all my models go
- views.py or views/ # where all my views go
- templates
- modelname
- all template related to this resource type
- scripts # where I put my scripts like backup etc
- lib # all utilities goes there
- subscribers # where all events are defined
My view package might sometimes be splitted up in many files where I'd group views by ResourceType.
If you happen to use context to match views instead of routes. You can do some pretty nice things with view_defaults and view_config.
view_defaults sets some default for the class, and view_config sets some more configurations for the defs using defaults provided by view_defaults if present.