django manage static files accessibility - django

example app tree:
articles
├── admin.py
├── apps.py
├── models.py
├── static
│   ├── css
│   │   ├── article_change.css
│   │   ├── article_create.css
│   │   ├── article_detail.css
│   └── js (obfuscated)
│   ├── article_create.js
│   ├── article_list.js
│   ├── edit_process.js
│   ├── editor.js
│   └── js (readable)
│   ├── article_create.js
│   ├── article_list.js
│   ├── edit_process.js
│   └── editor.js
├── templates
│   └── articles
│   ├── article_create.html
│   ├── article_detail.html
│   ├── edit_process.html
│   └── editor.html
├── tests.py
├── urls.py
└── views.py
static/js/js contains javascript that is human readable
static/js contains obfuscated javascript files.
I wrote a template tag to includes files:
#register.simple_tag
def jstatic(path):
s = ''
if settings.DEBUG:
s = 'js/'
return static(s + path)
in templates, I can do:
<script src="{% jstatic 'js/info.js' %}"></script>
which conditionally renders static javascript files based on DEBUG mode. whereas, if not in DEBUG mode, will serve obfuscated files.
the thing is, I don't want unobfuscated file to be accessed when DEBUG is not on, which is running the application on server.
when debug is on, I want user user only to visit obfuscated files:
static/js/js/info.js
and have no access to
static/js/info.js
all the apps follows this root tree convention, I wonder if there is a way, for me to block static/js/info.js is DEBUG is not on.
I have thought about shell setting directory permissions, but give up eventually. because, it will not work due to the wrapping structure of the directory. and it will be too much work to modify it, in the project there are about 20 apps.

This is not possible through standard configuration. How to solve this depends on your configuration, but there are three ways to solve this:
If you use some kind of minifier/webpack like configuration to obfuscate your JS files, you could move the JS files to a src directory and have your tooling only copy when DEBUG is True, and copy and obfuscate when debug is False.
You can use two static directories, one for readable files, and the other for obfuscated files (something like src/static/* and dist/static/*), and then only point to the source directory on development environments:
STATICFILES_DIRS = [ "src/static", "dist/static"] vs. STATICFILES_DIRS = [ "dist/static"] on production.
In this case, Django's static files finder will return the first match found.
Leave your configuration as is, but use a webserver like NGINX for serving static files (Which is already the recommended way to serve static files.) In NGINX's configuration you can define a location that 404's as long as it appears before the location serving your static files.

Related

How to generate coverage for multiple packages using go test in custom folders?

We have following project structure:
├── Makefile
├── ...
├── src
│   ├── app
│   │   ├── main.go
│ │ ├── models
│ │ ├── ...
│ │ └── dao.go
│   │   ├── ...
│   │   └── controllers
│ │ ├── ...
│ │ └── pingController.go
│   └── test
│   ├── all_test.go
│   ├── ...
│   └── controllers_test.go
└── vendor
└── src
├── github.com
├── golang.org
└── gopkg.in
I want to measure coverage of packages in src/app by tests in src/test. And currently generating coverage profile by running custom script that runs coverage for each package in app and then merges all coverage profiles into one file. Recently I heard that in go1.10 we are able to generate coverage for multiple packages.
So I tried to replace that script with oneliner, and tried running
GOPATH=${PROJECT_DIR}:${PROJECT_DIR}/vendor go test -covermode count -coverprofile cover.out -coverpkg all ./src/test/...
It gives me "ok test 0.475s coverage: 0.0% of statements in all"
When I do
cd src/test/
GOPATH=${PROJECT_DIR}:${PROJECT_DIR}/vendor go test -covermode count -coverprofile cover.out -coverpkg all
Logs show that specs are runned and tests are successfull, but still I have "coverage: 0.0% of statements in all" and empty cover.out.
What am I missing to properly compute coverage of packages in app by tests in test?
You can't with the current state of go test but you can always use third party scripts.
https://github.com/grosser/go-testcov
Short answer:
go test -race -coverprofile=coverage.txt -covermode=atomic ./... # Run all the tests with the race detector enabled
go test -bench=. -benchmem ./... # Run all the benchmark for 3s and print memory information
In order to create a test for a Go code, you have to create a file (in the same folder of the root code) that have the same name of the code, and append "_test" to the name. The package have to be the same too.
So, if I have a GO Code called strings.go, the relative test suite have to be named: strings_test.go.
After that, you have to create a method that have in input the t *testing.T
struct, and the name of the method have to start with Test or Benchmark word.
So, if the strings.go contains a method called "IsUpper", the related test-case is a method called TestIsUpper(t *testing.T).
If you need the Benchmark, than you need to substitute the Test word with Benchmark, so the name of the method will be BenchmarkIsUpper, and the struct that the method take in input is b *testing.B.
You can have a look at the following link in order to see the tree-structure necessary for execute the test in GO: https://github.com/alessiosavi/GoGPUtils.
There you can find Benchmark and TestCase.
Here an example of tree-struct
├── string
│ ├── stringutils.go
│ └── stringutils_test.go

how to configure nginx to indicate ’/‘ to my main page

i have a django project and my web static files are at 'web/' directory
here is the structure:
➜ web git:(ycw.alpha) tree -L 4
.
└── forward
├── asserts
│   ├── img
│   │   ├── background
│   │   ├── qr
│   │   └── thumb
│   └── style
│   ├── css
│   └── sass
├── index.html
├── package.json
├── script.js
├── source
└── unit
i have configured Nginx conf and i want nginx to directly indicate to 'web/forward/index.html' when i request my own website 'http://example.com'
i do the thing above like this:
location / {
index index.html
root /path/to/my/django/project/;
}
location /index.html {
alias /path/to/my/django/project/web/forward/index.html;
}
it indeed directly redirects to 'index.html', but the question is there are some references in 'index.html' to some static files such as img or css and the paths are relative paths like './asserts/style/css/index.css' so consequently these files are not found as 404
how can i configure it correctly?
The problem has been solved by changing 'root' in location / to '/path/to/the/index/directory' rather than the root directory of the django project, in this way you can still use relative paths of static resources in html file generally.

Is the directory structure expected for namespaced routes?

I've created a namespaced route called checkout.
I have the following in router.js.
// router.js
this.route('checkout', function() {
this.resource('payments', function() {
});
});
The following routes can be accessed via:
http://localhost/checkout/payments
However, the controllers, templates, routes for payment, don't exist in the the checkout directory. I would have imagined:
app/controllers/checkout/payments/index.js
app/routes/checkout/payments/index.js
app/templates/checkout/payments/index.hbs
But instead they exist and can be accessed by Ember in:
app/controllers/payments/index.js
app/routes/payments/index.js
app/templates/payments/index.hbs
Is this expected?
That it works at all is partially due to what Asgaroth describes: resources reset the namespace so in your example ember-cli is looking for a class Payments rather than CheckoutPayments, and partially due to ember-cli supporting two directory layouts (the regular one and the "pod" layout). While it builds the application it takes the name of classes from the file or the directory, depending on which is most appropriate.
You are basically mixing and matching the two approaches to the file system layout, which is why it works at all. But it would be incredibly difficult to figure out what belongs to what without a better structure in place.
Instead I'm using the ember generate --pod ... structure with them (which should become recommended for Ember 2.0), which results in a somewhat similar structure for my files as in your question:
app/map
├── debug
│   ├── controller.js
│   ├── route.js
│   └── template.hbs
├── index
│   ├── controller.js
│   └── template.hbs
├── settings
│   ├── controller.js
│   └── template.hbs
├── systems
│   ├── system
│   │   ├── route.js
│   │   └── template.hbs
│   ├── controller.js
│   ├── route.js
│   └── template.hbs
├── controller.js
└── template.hbs
And yes, you can nest routes (since Ember 1.7 or so) and with ES6 modules it brings little benefit to use resources over routes. I've stopped using them, as per the structure above my router.js now is a rather trivial:
this.route( 'map', function() {
this.route( 'systems', function() {
this.route( 'system', { path: ':system_id' } );
});
this.route( 'settings' );
this.route( 'debug' );
});
I can highly recommend the pod structure for your routers, controllers, mixins and components .. it takes some getting used to though, and your editor has to show directory names to be able to know what you are editing.
I don't think you can nest routes within routes are you sure you are not talking about resources?
A resource always resets the namespace.
The route, controller, and view class names for the comments resource
are not prefixed with Post. Resources always reset the namespace,
ensuring that the classes can be re-used between multiple parent
resources and that class names don't get longer the deeper nested the
resources are.
emphasys mine

Managing Static Files and Templates Django

I have gone through a few tutorials on creating a web application in Django. Based on the different tutorials so far, everyone seems to have a slightly different ways of storing their static files and templates.
In one particular tutorial, the author created a static folder at the same level as the project folder. Within the static folder, he created four more folders.They are :
media
static
static-only
templates
Within static, he created:
css
js
within templates, he stores all the web app templates such as base.html, aboutus.html, etc.
However, in the official django documentation, it says
https://docs.djangoproject.com/en/dev/howto/static-files/#serving-static-files-during-development
Store your static files in a folder called static in your app. For example my_app/static/my_app/myimage.jpg.
May I ask which is the most common way of doing it? Many thanks!
It depends. Since my apps share the same set of static and templates I store them in root dirs:
# Settings
STATIC_URL = '/static/'
STATIC_ROOT = abspath('static')
STATICFILES_DIRS = (abspath('styles'),)
STATICFILES_FINDERS = (
'django.contrib.staticfiles.finders.FileSystemFinder',
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
...
)
TEMPLATE_DIRS = (abspath('templates'),)
TEMPLATE_LOADERS = (
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader',
)
# All styles are in one place
├── styles
│   ├── less
│   ├── js
# App's templates are stored in privite dirs so I can move them in app dir any time
# without changing my code: flatpages/flatpage_detail.html Also it works well with
# class based views.
├── templates
│   ├── base.html
│   ├── flaptages/
│   │   └── flatpage_detail.html
│   ├── another_app/
│   │   └── another_app_detail.html
Then I do manage.py collecstatic and have all static in root/static dir.
It fits me. But if I would make an app to share with community I will put static and templates in it's own dir as described in docs.

Use cases for new Django 1.4 project structure?

I guess this is sort of a followup question to Where should i create django apps in django 1.4? The final answer there seemed to be "nobody knows why Django changed the project structure" -- which seems a bit unsatisfactory.
We are starting up a new Django project, and currently we are following the basic structure outlined at http://www.deploydjango.com/django_project_structure/index.html:
├── project
│ ├── apps
│ │ ├── app1
│ │ └── app2
│ ├── libs
│ │ ├── lib1
│ │ └── lib2
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
└── manage.py
But I think we also are anticipating a multi-developer environment comprising largely independent applications with common project-level components, so it seems cleaner to me to separate out the project and app paths.
├── project
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── apps
│ ├── app1
│ └── app2
├── libs
│ ├── lib1
│ └── lib2
└── manage.py
It's hard to come up with any specific, non-stylistic rationale for this, though. (I've mostly worked only with single-app projects before now, so I may be missing something here.)
Mainly, I'm motivated by the fact that Django 1.4 seems to be moving in the latter direction. I assume there is some rationale or expected use case that motivated this change, but I've only seen speculation on what it might be.
Questions:
What was the motivation for the 1.4 project structure change?
Are there use cases where having apps inside/outside of the project makes a non-trivial impact?
It's much easier to extract an app from a project because there are no more imports like this:
from projectname.appname.models import MyModel
instead you import them the same way you would import apps which are installed via a python package
if you use i18n then this could make an impact because makemessages searches for translation strings in the current directory. a good way to translate apps and the project using a single .po file is to create the locale folder outside the project dir
├── project
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── app1
├── app2
├── locale
│ ├── en
│ └── de
└── manage.py
I marked the earlier response as an answer, but I ran into this blog post off the IRC archives that seems to have some additional info.
http://blog.tinbrain.net/blog/2012/mar/15/django-vs-pythonpath/
As I understand it, the gist is:
When you're developing, manage.py implicitly sets up PYTHONPATH to see the project-level code, with the result that import myapp works for an app defined inside the project.
When you deploy, you generally don't run manage.py, so you would have to say import myproject.myapp, thus things break on deployment if you don't know about this.
The "standard" fix is to add the project to PYTHONPATH, but this results in double-imports (myapp and myproject.myapp), which can generate weird behavior on things like signals.
So the 1.4 project structure seems mainly intended to eliminate the possibility of devs relying on an odd effect of manage.py.