Often its useful to get error information for ajax/javascript errors happening on various clients. This can go to something like this:
# error_sink
def error_sink(request):
# post request, with event name in "event", and event data in "data"
context = request.REQUEST.get("context", "")
context = cgi.parse_qs(context)
context["data"] = cgi.parse_qs(context.get("data", [""])[0])
context["user"] = request.vuser
context["referrer"] = request.META.get('HTTP_REFERER', "referrer not set")
context = pformat(context)
send_mail(
"ajax error", context, "[email protected]",
["[email protected]",], fail_silently=True
)
return JSONResponse({"status": "ok" })
# }}}
- ajax
- jquery
- error
- reporting
Jinja2 is an alternative template system that can be plugged into django.
It offers greator flexibility in presentation logic; if you find the django template system too restrictive, you should have a look at Jinja2
(The syntax is very similar).
In Jinja, you don't need costum tags (most of the time), because you can call functions and pass them parameters too!
The only problem is that you cannot "load" functions from the template, this "loading" must be done by the code that renders the template. Same goes for filters and tests.
If you need only two or three functions/filters, no problem, you can manually add them to the Environment object; but this method doesn't really scale with real-life webapps.
This module/snippet offers a solution by allowing the user to define application-specific functions and filters and load them into the jinja2 environment automatically.
Here's how to use this:
1. Install Jinja2 (for a quick & dirty installation, you can just put the jinja2 folder in a folder that's in PYTHONPATH)
2. Save this python module somewhere and call it something meaningful (I have it as jinja.py in my project directory)
3. Whenever you need to respond (an HttpResponse) with a template that's rendered by jinja, import this module and call `return jrespond( template_name, context )`
4. Any filters or functions you define in any of your applications will be readily available inside the template (see the documentation in code)
- template
- templates
- jinja
- template-tags
- jinja2
In the past, whenever I had a script that I wanted to properly configure the settings for, I would use something like the following idiom at the top of the script:
import sys, os; dirname = os.path.dirname
# sys.path.insert(0, dirname(dirname(__file__)))
sys.path.insert(0, dirname(__file__))
os.environ['DJANGO_SETTINGS_MODULE'] = 'myapp.settings'
Notice that this is a relative setting to `__file__` variable in the script. The djangopath function is an attempt to do away with the above such that I can now write the following:
from lib import djangopath; djangopath(up=2, settings='myapp.settings')
This seems to work for me, but it assumes that you are packaging your script inside your projects/apps. If they are elsewhere then you may need to resort to another method (e.g. absolute paths, etc.)
AK