Pick a default extension for Django templates

[Allan Odgaard]

It seems that the default extension for Django templates was HTML and now sort of “not specified”.

I would strongly encourage you to pick a default extension, for example ‘django’ or ‘dhtml’ (not an extension already in use, like ‘html’.)

An official extension allows both to have OS icons for the Django files [1] and out-of-the-box editor support [2].

If you do not make this choice for the user, every user will have to setup these things for themselves, and for the former, that is definitely not trivial.

I would further add that you burden the user with unnecessary choice, choice which not only rule out the previously mentioned “nice defaults” but also lead to inconsistency, as the file extension is today the way majority of “systems” recognize file types, be it operating systems, web servers, applications, or similar.

[1] On OS X there are document icons for majority of file types. These show the icon of the application which opens the file and the short-name for the type below. A user would never set this up himself, but instead rely on an application to supply the icon, but the mapping is based on file extension, so a mapping for Django can never be created as long as you do not mandate a file extension.

[2] TextMate (which I am the author of) stores support for a particular language in a bundle (many included by default, but otherwise installed by double-clicking). Within this bundle is stored which file extension it should apply to by default. It is trivial to educate TextMate about additional mappings, yet it is also a FAQ entry because we get the question a lot.

[Antonio Cavedoni]

I’d second Allan’s request. For this editing mode for Django templates for Emacs I picked the default extension .djhtml, BTW.

[Michael Sheets]

I've been thinking this for a while as well, it becomes annoying because while you can set .html files to be Django files that change affects all my HTML files. Obviously not a very good option. One could say that because it's changeable that it's fine, but a reasonable default is a good thing. Being that a lot of learning Django is looking around at what others have down it can be hard when the standard extension conflicts. Using a custom extension for yourself can't fix that.

Could be something still based in html like .dhtml, or something more abstracted like .dtmpl or .dview The important thing is it be unique enough to prevent conflicts and allow editors easier detection.

[cgrady@…]

.djt for django template ?

dhtml/djhtml isn't the best, because templates aren't necessarily HTML, and registering .dtxt/.dhtml/.dxml/etc would be a bit repetitive :)

[Luke Plant]

Personally I wouldn't use any special extension. If I'm creating HTML templates, then I'd usually want emacs to display the files in HTML mode, so .html would be the obvious extension to use -- anything else I'd have to configure extra, and I'd need a different one for every type of file I use Django templates for. The extension should be the same as the underlying type of text the template is for. It could possibly be .django.html and .django.txt, allowing editors to distinguish between them if necessary.

Second, as far as I know Django never actually creates template files for the developer, so how does picking a default file extension change anything?

Finally, to support this as you describe, the Django installer would have to set up these file types, the process for which is very different on GNOME, KDE, Mac and Windows, and whether those settings are respected depends on your editor anyway. It would be very strange IMO for a library (which is what Django is ultimately) to be installing file types like applications do, especially for Python libraries which are usually packaged in such a way that 'unpack the tarball' is a valid installation procedure.

BTW, in emacs you can get the django mode to be used by adding {% comment %}-*-django-*-{% endcomment %} as the first line of a template.

[Allan Odgaard]

lukeplant: the “installer” for Django should not install file type icons etc.

That is the point of mandating a default extension — Django would only put this in the documentation or wherever it makes sense. Then other applications will know that this is the Django extension. TextMate comes with icons for 80 or so different document types, I would then include a Django icon bound to the extension picked (currently not possible w/o knowing which extension to target) — on Linux it might be that it is KDE or GNOME which bundles these document icons.

Likewise the Emacs mode for Django, or the Django mode in vim, TextMate, or similar, would automatically be active when the file was using the mandated file extension.

So the request is for a standard! This standard then allows third party applications to improve the user experience “out of the box” and does not result in the problem that e.g. a user receiving a sample Django project sees this as plain HTML because the author of the project had chosen a different extension etc.

That you want to see Django files as HTML is only because you have no dedicated Django mode, as soon as you have one, you face the problem mentioned by Michael Sheets above.

[James Wheare <django@…>]

I actually find Django's flexibility here quite useful. Rather then enforce a homogenous file extension, it allows you to easily see what sort of file the template is actually being used to generate. Using .dtmpl or whatever means you have to open the file up to see whether it's javascript, xml, html, txt, csv or whatever. You already know it's a Django template because it's in the templtes directory. In order to keep this glance-ability, you'd have to name your templates like 'main_html.dtmpl'

So the argument is, should you enforce/encourage a convention for the sake of software at the expense of programmers? I'd err towards the human side of this conflict myself.

That said, the Django docs could *suggest* a standard extension should template authors want to take advantage of painless syntax highlighting, while still allowing any extension to be used. Then it's the coder's choice, and admittedly once you've been working on a project for a while, you're likely to know which files are which.

So ideally, the grammar detection features of TextMate shouldn't rely on file extension (I believe this is the plan for TextMate 2.0), but in the meantime, perhaps an agreed standard extension can be officially suggested. It should be made clear what the benefits are and that it is NOT enforced.

I'd also like to argue strongly against .dhtml or anything that references an existing extension as this would just be confusing.

[Allan Odgaard]

James: there is precedence for double-extensions (which is supported for TM language grammars), e.g. using js.django, html.django, etc. This would then gracefully degrade to just django for systems not supporting double-extensions (i.e. all Django files would get the same Django document icon in Finder).

FYI TextMate 2.0 will still rely on extensions as the primary way to identify file types — anything else is fragile and/or clumsy. What I was referring to in this ticket ​http://macromates.com/ticket/show?ticket_id=DFDBA0AA is the ability to have project type detection and use that to change HTML files to be Django only for Django projects. But this is not ideal, e.g. stand-alone Django-files are then not recognized correctly, it still does not allow a document icon to be assigned to Django files, and this is a TextMate-specific workaround, similar to how the Emacs modeline (as suggested by lukeplant) is also an editor-specific workaround.

[anonymous]

I prefer *.dt !
Because *.djt is good readable under graphical environment (*.dit , *.djt).
*.dhtml or *.djhtml is to long and django templates can do more then html.

[anonymous]

I meant *.djt is not good readable under graphical environments!

[Chris Beaven]

Personally I'm -1 on this ticket.

[Malcolm Tredinnick]

As per Luke Plant's comment, we are extension neutral precisely because you are intermixing Django templates with other syntax. That is why we removed the .html extension in the first place. Filetype detection based on extension is flawed for the very reasons described in these comments, so you have to do some internal inspection, just like MIME type detection works.

Vim gets it mostly right (it could be a little more bulletproof); other apps should be able to manage.

[Allan Odgaard]

So for all these flawed programs which rely on extensions to tell what the file contains, could you please tell us which heuristic we should use to detect Django files?

[Allan Odgaard]

Also, could you please tell me what exactly you mean by “Filetype detection based on extension is flawed for the very reasons described in these comments”?

The only thing I see is that a Django file can be used with more than just HTML — but I already suggested a workaround: double extensions.

By using double extensions, e.g. “.html.django” you will have ALL programs understand that this is a Django file (contrary to now, where NO programs can recognize the files) and IN ADDITION you have a bullet proof way to further have the program recognize that the Django file contains HTML (in addition to the Django-specific syntax) — sure, not all programs understand double extensions (or can be made to), but the system gracefully degrades, i.e. those programs still get that it is a Django file, and for most programs (i.e. all but text editors), that is enough (yes, non-text editors also occasionally need to recognize file types).

I am really baffled by the unwillingness to pick an extension for Django files. You don’t want your OS to show a custom icon for these files? show that it is a Django file in the verbose file type field? have your editors automatically pick the Django mode when opening these files? etc.?

All this is possible if an extension was chosen. Without one, we have, according to you, one editor which almost gets it right (I really fail to see how you can identify a file based on content though, the file could be empty).

[Luke Plant]

The problem with your double extension idea is that many editors may not be so easily configurable as TextMate. In that case, you have HTML templates and plain text templates etc all with the same extension i.e. .django, instead of the normal extension, .html/.txt/.js. So now, neither my editor nor my operating system know what to do with these files, whereas before they would have opened them correctly as HTML, plain text and javascript files respectively, which is what I wanted (I don't happen to use a Django mode when editing any of these templates).

I actually don't want my operating system to give me special icons for these templates -- I want them to display the icon for the underlying file type. Also, when I am browsing files, my operating system displays previews automatically, and using my convention it gets the previews for HTML correct without any configuration -- see ​http://files.lukeplant.fastmail.fm/public/konq_html_preview.png -- and I like this very much.

So, for me, .django.html etc. would work much better (although just .html works fine, and .django is just more stuff to type). However, there is a case for .html.django, especially if you have just one editor for Django templates, or one Django mode in your editor.

The point I'm making is that what works for you doesn't necessarily work for me, and in fact may make my life harder -- the convention you have picked does not degrade gracefully in my case. (Sorry if that sounded confrontational -- by 'you' and 'me' I mean 'one person' and 'someone else'). Rather than get mixed up in the politics of all this, Django is just extension neutral. Authors are free to pick conventions that suit them and their tools. If you receive files from someone else, you have to live with their conventions (just like living with tabs vs spaces in code files), or use tools which will minimise the pain.

[Allan Odgaard]

Replying to lukeplant:

Luke, our disagreement, based on your response, is only on what we consider the primary type of the file.

This ticket is requesting a default extension for Django files, this could be in the form of “django.html”, “django.css”, etc. — personally I would swap the order, but this is a separate issue, and of much less significance than the actual issue of having a default extension.

ASP, ColdFusion, ERb / RHTML, Mason, PHP, and all the other popular template languages (mostly used with HTML) recognize the value in having programs be able to recognize the file type. Why does the Django community not see the value in out of the box Django support from text editors and the likes?