Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Suffix all armstrong custom templatetags with '' #78

pydanny opened this Issue · 4 comments

3 participants


The deeply nested architecture of armstrong makes discovery of templatetags challenging. A practice I've seen adopted by a lot of projects is to suffix all templatetags with '_tags' simplifies discovery. It's a very handy convention:


I'm -0 on this one. Couple of problems:

  • The biggest is that it would break backwards compatibility.
  • Breaking filters and tags into two modules seems redundant to me.

FWIW, in Sublime Text 2 and Vim it's pretty simple for me to see the various tags by searching for arm/temtags/ and now I'm listing everything that contains arm and temtags in it.


You don't have to remove the old tag file names. You can simply import the content into new file names and begin the process of migrating over.

As for using a particular text editor as justification for a coding convention, does that mean that only Sublime Text 2 and Vim are supported by Armstrong?


I'm not a fan of more than one way to do something, I'd much rather have one way to load the template tags and filters rather than an old one and a new one unless there's some gain to be had by switching. I guess there's a case to be made for treating the _tags and _filters modules as private and not meant to be loaded directly, but still exposing them in case you needed further granularity in what gets loaded. At that point when do you stop though? Should each template tag and filter be in a module by itself so you have the option of loading just it? That seems like adding extra complexity and further nesting for no real gain. Am I missing something?

We don't have support for one or two editors, I was merely pointing out that any sufficiently modern editor (including the > 20 year old Vim) is capable of using the full path to figure out where things are. I see no need for Hungarian-esque suffix to add to that, if anything having the _tags suffix is a determent as most (all?) partial matching in editors use the order of the characters entered as its way to match.


-0 for me too. I don't see the gain.

Armstrong doesn't use many templatetags so there isn't a need to break up long files into *_tags and *_filters. Also, you can always {% load filter from templatetag %} to 'import' just one thing from a templatetag file.

Discovery may be slightly cumbersome, but at least they always exist in a templatetags/ directory. I think the better way to discover tags and filters is through the documentation. It's part of learning how and why a component of Armstrong works.

@tswicegood tswicegood closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.