A template loader useful for writing templates with carefully controlled newlines and spaces while retaining readable template source code formatting.
Start the template with PTFTAG (`{#ptfable#}`, here) to allow it to be processed. Common problems with doing it to most templates as-is is use of newlines to separate words and multiple spaces between tags where spaces are still needed (which is problematic with `spaceless` tag as well).
Currently intended as a template loader wrapper, and is suggested to be used with cached loader. Example settings.py configuration:
_lp = lambda lo, *ar: (lo, ar,) # loader, arguments
TEMPLATE_LOADERS = (
_lp('django.template.loaders.cached.Loader', # cache
_lp('ptf.template.ptftemplateloader.Loader', # ptf
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader',
#'django.template.loaders.eggs.load_template_source'
), # ptf
), # cache
)
(change `ptf.` to wherever in python path you've put it).
You might also need couple of simple template tags for explicitly inserting newlines or whitespaces:
def br():
return "\n"
br = register.simple_tag(br)
# XHTML-XMPP-template compatible.
def brx():
return "<br />\n"
brx = register.simple_tag(br)
def ws():
return " "
ws = register.simple_tag(ws)
.
This is extremely simple decorator to add possibility to upload files with name specific in some object field. For example image with same name as object slug.
Sample **model**:
class Test(models.Model):
image = models.ImageField(\
upload_to=upload_to_dest(path='pics/', \
human_readable_field='hrname'))
hrname = models.CharField( \
max_length=128, \
blank=True, default='')
Sample **form** for admin:
FNAME_EXP = re.compile('^[A-Za-z0-9\-\_]+$')
class TestAdminForm(forms.ModelForm):
hrname = forms.RegexField(
label="Human Readable File Name", \
regex=FNAME_EXP, \
help_text="""Allowed only latin alphabet
(upper and lower cases),
underscore and minus
characters. PLEASE, DO NOT INCLUDE
EXTENSION OF THE FILE.
Sample: test-this-file""", \
required=False)
class Meta:
model = Test
Sample *admin.py* for *Test* model:
class TestAdmin(admin.ModelAdmin):
form = TestAdminForm
admin.site.register(Test, TesetAdmin)
- django
- ImageField
- file uploads
- file name
- FileField
FastCGI handler in prefork mode first imports every application, then forks. If any application during import opens connection to database, open connection is inherited by all of child processes; open db connection cannot be shared between processes, and if one process sends a request, another can receive a reply; also, if one process closes it, others have a desynchronized database handle.
See:
* http://stackoverflow.com/questions/1573579/psycopg2-disconnects-from-server
* http://stackoverflow.com/questions/393637/django-fastcgi-randomly-raising-operationalerror
* http://code.djangoproject.com/ticket/13215
* http://groups.google.com/group/django-users/browse_thread/thread/2c7421cdb9b99e48
If you put this snippet in your project-level __init__.py, then running manage.py runfcgi will fail loudly if the database connection is open in the parent process. This will happen only when you provide debug=true option to runfcgi to avoid monkey-patching code that runs in production mode.
**NOTE: This is modified from 1.0's test runner and has only been tested on Django 1.0 + Python 2.5**
This is a test runner that searches inside any app-level "tests" packages for django unit tests. Modules to be searched must have names that start with "test_" (this can be changed by modifying `get_multi_tests()`, [`mod.startswith('test_') and mod.endswith('.py')`]).
It also allows for arbitrarily nested test packages, with no restrictions on naming, so you could have:
myapp/
+- tests/
+- __init__.py
+- test_set1.py
+- category1/
+- __init__.py
+- test_something.py
+- subcat/
+- __init__.py
+- test_foobar.py
+- category2/
+- __init__.py
+- test_other.py
and "manage.py test myapp" would pick up tests in all four test_*.py test modules.
Searching the modules in this way, instead of importing them all into the top-level `__init__.py`, allows you to have "name collisions" with TestCase names -- two modules can each have a TestFooBar class, and they will both be run. Unfortunately, this snippet doesn't allow you to specify a full path to a specific test case or test module ("manage.py test myapp.category1.test_something" and "manage.py test myapp.test_set1.TestFooBar" won't work); using "manage.py test myapp.TestFooBar" will search out all test cases named "TestFooBar" and run them. "manage.py test myapp.TestFooBar.test_baz" will work similarly, returning the test_baz method of each TestFooBar class.
To use, put this code in "`testrunner.py`" in your project, and add `TEST_RUNNER = 'myproject.testrunner.run_tests'` to your `settings.py`.
- tests
- test-runner
- package
Other approach of making middleware. Advantage of is to specify, which middleware is used for which view function and in what order. Middleware function gets all arguments, that are passed to view function.
**Example usage**
@RequestMiddleware
def print_params_middleware(request, *args, **kwargs):
print 'GET params:', request.GET
@ResponseMiddleware
def modify_headers_middleware(request, response, *args, **kwargs):
response['Content-Type'] = 'text/html'
@ExceptionMiddleware
def catch_error_middleware(request, e, *args, **kwargs):
return HttpResponse('catched error %s' % e )
@modify_headers_middleware
@catch_error_middleware
@print_params_middleware
def some_view(request, *args, **kwargs):
print 'someview'
return HttpResponse()
- middleware
- decorator
- exception