I tried a few snippets of integrated jinja2 in django, which provided ?.render_to_string and ?.render_to_response in the way of jinja2. **But those snippets could not use the generic view**, because of the generic views is use default django template. so i write this snippet which could use generic view, and use the basic django.shortcuts.render_to_string, django.shortcuts.render_to_string.
#in yourproject/urls.py :
#install default environment is very simple
djangojinja2.install()
#install environment of specified Environment class
from jinja2.sandbox import SandboxedEnvironment
djangojinja2.install(SandboxedEnvironment)
#alternative you can install sepcified environment
env=Environment(...)
...
djangojinja2.install(env)
#something could be set in settings.py
TEMPLATE_DIRS = (path.join(path.dirname(__file__),"templates"),)
JINJA_GLOBALS=['myapp.myutil.foo',]
JINJA_FILTERS=['django.template.defaultfilters.date',]
JINJA_TESTS=('foo.mytest',)
JINJA_EXTS=['jinja2.ext.i18n']
#there is no change need for app.views
from django.shortcuts import render_to_response
def foo(request):
return render_to_response('/myjinja2.html',{'request':request})
test in django development version of r12026 , jinja2 2.2.1, python 2.5
- template
- generic
- jinja2
- generic-view
Okay - so I came across a really annoying problem earlier, where I wasn't able to *easily* load a formwizard as a segment into an existing view, and wrap it using my existing site template layouts. This was *REALLY* annoying. Especially since I wanted to keep as much of a 'overall' templating and application logic in the views.py (and just leave the forms.py to handle the form and its own templating for the form pages)
I spent about 2 hours trying to make this as conventional as possible, and finally came up with a solution. The result is something which looks as similar to the usual functionality. This also meant that there is seperation between form styling and overall site styling, so your forms can be used between multiple sites, and if your overall site template uses extends, then the context support keeps this nicely in order.
This also allows you to initialise the formwizard in a nicer way.. Of course, in each file, you'll need to import the necessary bits (like importing the testform from the view etc)
- requestcontext
- views
- context
- form
- urls.py
- wizard
- formwizard
- views.py
In test code, it is sometimes useful to monkeypatch a Django method to have stubbed out behavior, so that you can simplify data setup. Even with decent data setup you might want to avoid execution of Django code that is not the target of your test.
The code snippet shown here illustrates a technique to limit the scope of your monkeypatches. It uses the Python "with" statement, which was introduced in 2.5.
[with statement](http://effbot.org/zone/python-with-statement.htm)
The key aspect of the "with" machinery is that you can set up an __exit__ method that gets called even if the code inside the "with" raises an exception. This guarantees that your monkeypatch gets un-monkeyed before any other code gets called.
I don't recommend monkeypatches in production, but if you HAVE to resort to a monkeypatch, I definitely advise using "with" to limit their scope.
The examples on the left illustrate how to suppress versions of reverse() and timesince()--look at the import statements to see which ones I am talking about. Obviously, monkeypatching is not for the faint of the heart, as you need to be able to find the code to monkeypatch in Django source, and you need to be sure there aren't decorators at play.