How can I access the WSGIScriptAlias from my django settings file? - django

I have this line in my wsgi.conf file:
WSGIScriptAlias /trunk "c:/app/trunk/app.wsgi"
Inside of my django settings file, I need to know the alias "/trunk" to get LOGIN_URL to work properly. How can I retrieve this value from my apache settings?
Thanks!
Pete

Access the original WSGI environ dictionary for a specific request and lookup the 'SCRIPT_NAME' variable. The value of this is the notional mount point for the WSGI application as specified when using WSGIScriptAlias. Getting it through the per request environment is the only real way of doing it automatically. You cannot get to it from outside of a request and there should be no real need for you to do that.
By rights, Django should provide a way of automatically having the mount point of the application inserted into configured URLs such as that. You should perhaps bring up the issue on the official Django users list instead if you cannot find the way of doing it as perhaps a change in Django is needed.

Since you want to obtain a value from the Apache configuration, I guess the only thing you can do is read the file and process it.
Something like (assuming your settings.py lives in the same directory as wsgi.conf):
try:
f = open('wsgi.conf', 'r')
LOGIN_URL=[line for line in f.readlines() if 'WSGIScriptAlias' in line][0].split()[1]
finally:
f.close()
Catching an exception if the file is not there might be a good idea too.
Edit after your comment: Ah, I see what you are trying to do. This thread may be helpful in understanding why using os.environ won't work. The alternative they present won't help you though:
In a nutshell, the apache SetEnv isn't setting values in the process
environment that os.environ represents. Instead SetEnv is setting
values in the context of the WSGI request.
Within your code you can reference that context at request.environ:
def myView(request):
tier = request.environ['TIER']
It's me again. Because of what Apache's SetEnv is doing, I don't think you will have access to the variable in settings.py. It seems parsing the file is still the only option.
Further Edit: Another alternative - can you base your decision on the host name?
#settings.py
import socket
production_servers = { 'server1.com': '/trunk...',
'server2.com': '/trunk_2...' }
LOGIN_URL=production_servers[ socket.gethostname() ]
This completely sidesteps the information contained in apache configuration.

Related

variable in setting file using in template

everybody! I want to access to constants value that I declare in my setting.py file to use in my template, but not in a template inside the app, I just want to use in my home template the template that I declare in my setting file.
CMS_TEMPLATES = (
## Customize this
('page.html', 'Page'),
('feature.html', 'Page with Feature'),
('homeTemplate.html', 'Home Template') // I want to use here
)
I found this example about the same problem in StackOverflow, but all case uses the variable inside apps not in top level.
How is the best way to use this value inside this template!!
I'd start by asking - why do you want to do that? It seems like an odd way of... adjusting the templates directories that you're using, i guess??
I wonder if you may have an XY problem. If you post what you're trying to achieve, that might be better than a specific solution to this specific problem.
Broadly though, you can only serve django variables (including from settings.py) inside a project or script that's using Django, or at least its environments. Doing from django.conf import settings imports the settings that are available at the highest level in the project, across all of the apps. Projects are laid out in this rough fashion.
myproject -
- myapp1
- myapp2
- myproject
- settings.py
- wsgi.py
- manage.py
As in this answer, For external scripts, you can still import the django settings thus:
import os
import django
from django.conf import settings
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')
django.setup()
# now you can use settings.VARIABLE_NAME
But: this still won't get it into a template, because getting the variable from here into a template needs you to use the django engine to render a response.
If it's not being served by the django system, it's not a template, it's just a regular html file.
If it's a template in another app in your overall project, you would pass it as part of your context dictionary, as laid out in the docs on templates.

To use Django FileField or FilePathField?

I'm a bit confused about which field to use. What I need is just a Field that will hold a file (audio and/or another one for an image)
The FileField seems to be specifically for uploading and I think it is a bit of overkill for what I need, I also don't like how it will automatically upload and rename the files to a unique filename (file_FHjgh758.txt) everytime something is uploaded.
The problem I have with the FilePathField is that it seems to require an absolute path, which would obviously be different from dev to production, I got around this by adding this to the model...
import os
class Foo(models.Model):
path = os.path.dirname(os.path.dirname(__file__))
path = os.join(path, 'media')
audio = models.FilePathField(path=path)
I have no idea if this is safe or proper, and there aren't many examples online or in the docs to draw from.
To be clear, I just want to have a field which I can point to a file (audio or image) somewhere in my system. What would be the best way to go about doing this?
If you want to refer to files that are already on your filesystem rather than user uploaded files, then FilePathField is the one that you want.
In this regard a few comments:
Don't point to a path that is inside your app's source tree. That is not safe.
You can use settings or environment variables to handle development vs. production paths, e.g., put a FILE_PATH_FIELD_DIRECTORY setting in your development/production settings files and refer to this setting from your app:
from django.conf import settings
class Foo(models.Model):
audio = models.FilePathField(path=settings.FILE_PATH_FIELD_DIRECTORY)

What is the format of the django config file for manage.py?

I'm hooking up selenose (selenium) tests and using liveserver in the process. It appears that I automatically start running into problems with ports being used so want to configure liveserver to use more that one port. I see how to do that via the command line (--liveserver=localhost:8100-8110) but would like to use a config file.
I have one I'm using for nose already and thought I might be able to reuse it but can't find anything to support that belief and my test runs say it won't work. I was expecting to be able to add something like the following:
[???]
liveserver=localhost:8100-8110
but replace the '???' with an actual header.
for some reason django uses an environment variable for this. you can set it in your settings if you want
import os
os.environ['DJANGO_LIVE_TEST_SERVER_ADDRESS'] = 'localhost:8000-9000'

Error when trying to load Django custom filters into template

I've inherited a Django application that I need to modify using a custom template filter. I'm absolutely new to Django and am quite mystified by it. I thought I had followed the instructions exactly, and also followed all the advice from other posts on the subject, but I still get an error when I include the following line in my template:
{% load mlgb_custom_filters %}
My directory structure is as follows:
mysite (i.e. the project)
__init__.py
mlgb/ (i.e. the app)
__init__.py
templatetags/
__init__.py
mlgb_custom_filters.py
The code of mlgb_custom_filters.py is as follows:
from django import template
from django.template.defaultfilters import stringfilter
register = template.Library()
#register.filter(name='fix_dashes')
#stringfilter
def fix_dashes( value ):
return value.replace( '--', 'DASH' )
if __name__ == "__main__":
testvar = fix_dashes( "ouch -- ow -- I hate django" )
print testvar
As you can see, I've added a 'name = main' section to let me run it in standalone mode, just to check that there are no errors in that particular file, and it's fine when run in standalone mode.
Based on someone else's advice, I've also tried importing it into another file, just to see whether there was an import error, and once again, it was fine if I added this to the end of settings.py (while using the dev server):
try:
import mlgb.templatetags.mlgb_custom_filters
except Exception, exc:
print 'error importing mlgb_custom_filters'
print exc
Also, INSTALLED_APPS in settings.py includes the line 'mysite.mlgb', and I have also tried putting just 'mlgb' instead of 'mysite.mlgb' there, as yet another person suggested. And I restarted the dev server every time I made a change.
I think I have tried every single suggestion that I have found on the web until now. Does anyone have any new ideas? Could it be anything to do with the fact that I have inherited a directory structure where the template directory is not within the same structure as the application, i.e. it is not under mysite? Scraping the barrel for ideas here! I hope someone can help.
OK, in the situation that I was in when first posting this question, it seems all I actually needed to do was touch a wsgi file under my appname/apache directory to force the application to be refreshed. Yesterday's initial answer was a red herring. Basically I should have touched the file myproject/myapp/apache/myapp.wsgi. Then maybe restart Apache for good measure? But the confusion was caused by the fact that apparently it wasn't enough either simply to restart Apache or to manually recompile the Python. In order to pick up my changes, seems like I needed to touch that wsgi file. Then all is well.
I can now post an answer to my own question thanks to the help of my colleague Masud Khokhar, whose brilliant detective work has saved the day. To recap, my application worked fine until I added a 'load' statement to one of my template files, to load a 'custom filters' module. Masud identified that now I needed to use a full/absolute path to the template file in urls.py instead of a relative one as I had before (and which worked before, until it needed to load the custom filters module). So, in urls.py, I had a section of code as follows:
url(r'^book/(?P<object_id>\d+)/$', 'list_detail.object_detail',
kwargs={
'queryset':Book.objects.all(),
'template_name' : 'mlgb/mlgb_detail.html'
},
name='mlgb_detail'
),
Instead of this:
'template_name' : 'mlgb/mlgb_detail.html'
I needed something like this:
'template_name' : '/THE_FULL_PATH/mlgb/templates/mlgb/mlgb_detail.html'
Made that change - sorted! Thank you once again, Masud.

Save FileField file uploads someplace other than MEDIA_ROOT?

Can I use FileField to handle a file, but store it someplace not under MEDIA_ROOT/MEDIA_URL but somewhere else entirely.
Seeking is to ensure it is not downloadable; although denying read permissions would do the trick here's hoping for something better... like a different directory altogether.
There are a few ways to do this.
First, you can take a look at handling uploaded files from the Django docs. If you read it over, basically you can handle the upload of the file within your view in the same part where you are processing your form.
Another option, and one which I think would be better is to use a custom file storage system. You could do this very simply using the existing one as a base but simply change the location, then use it as an argument in your FileField. For example:
from django.core.files.storage import FileSystemStorage
my_store = FileSystemStorage(location='/some/other/dir')
class SomeModel(models.Model):
file = models.FileField(storage=my_store)
Hope that helps!
Considering that the only actual use of MEDIA_ROOT in all of Django is to determine where uploaded files are stored, seems like it would make more sense to just point MEDIA_ROOT where you want your uploaded files, and then use a different setting for the path to your static assets. This is the approach taken by Pinax and django-staticfiles, which use STATIC_URL and STATIC_ROOT settings.
Note that even the documentation page on serving static assets in development no longer recommends using MEDIA_ROOT for that purpose, it demonstrates using your own STATIC_DOC_ROOT setting.