+==================== conventions for templates & static files
+==================== and NOTES on using the development server
+
+. first off, running manage.py runserver is provided by django as a development convenience but
+ SHOULD NOT be used in production
+
+. second, when you do use it for developement purposes, please be aware that:
+
+.. the recommended layout for the various files and pieces (py, html, js and css) with django is
+ IMHO really painful; we *SHOULD* use e.g.
+ plugins/simplelist.py,
+ plugins/templates/plugins.html,
+ plugins/static/js/simplelist.js
+ plugins/static/css/simplelist.css
+ which I have tried doing for a while but I found mmyself just hopping around in the file tree all
+ day long, wasting cycles all along
+
+.. as that does not make sense IMHO, I've rewritten the tool for gathering these pieces (this is in
+ the Makefile). Bottom line is we can essentially store this wherever we want.
+ The only restriction being that if you have a template that is *not* html, then it *has to* sit
+ in a templates/ directory, otherwise it gets shipped as a static file.
+
+.. as a result, we can now store all the files building a plugin in a single (git) directory; like e.g.
+ plugins/quickfilter/quickfilter.py
+ plugins/quickfilter/quickfilter.html
+ plugins/quickfilter/quickfilter.js
+ plugins/quickfilter/quickfilter.css
+
+ Of course it's a completely different matter once the service is packaged and installed, these
+ files of course get properly separated.
+
+.. as a result it is a little bit less convenient to use the development server when you change the
+ layout of your static and template files, you might need to re-run 'make static', so it is
+ recommended to use devel/server-loop.sh instead
+
+
+All this being said, here are our current conventions for storing templates and static files