Because {% now "Y"|add:"-2005" %} - etc. doesn't work, you can use the above in your template like:
We have {{ 2000|since }} years of experience.
or:
Serving our customers with passion for more than {% years_since 2005 %} years.
Function that takes a bound form (submitted form) and returns a list of pairs of field label and user chosen value.
It takes care of:
1. fields that are not filled out
2. if you want to exclude some fields from the final list
3. ChoiceField (select or radio button)
4. MultipleChoiceField (multi-select or checkboxes)
Usage:
if form.is_valid():
form_data = get_form_display_data(form, exclude=['captcha'])
It's trivial to display the list of pairs in a template:
{% for key, value in form_data %}
{{ key }}: {{ value }}{% endfor %}
Fixed-point model field based on `IntegerField` and `DecimalField`. Represented as `Decimal` in Python for accurate calculations, stored as integer in the database. Configurable decimal places, defaults to 2.
Provides UUIDField for your models. This version creates very short UUID represenation (21 chars) when the record is added eg. in admin. Generated ids are safe to be used in URLs.
You can put represent it in admin as
'readonly_fields=("uuid",)'
Everybody know about long spagetty-style settings file for django :-)
I tried to find any cool settings loader, but have no luck.I created this one myself.
Ok, we forgetting about `settings.py` and creating module settings (folder named settings with file `__init__.py`).
This `__init__.py` file have preloader for modules placed in settings folder and `../settings_local.py` (if exists) at the end. settings_local is awesome tool, when you use any VCS like git and have settings in vcs, but for example you have different database connection settings. You can change this settings in settings_local.
Settings splitter have variable moduleweights. This variable declares weights for selected modules to allow loader sort modules by priority and use already defined settings in each other loaded module. You can define your custom modules and weights there.
Ok, now few examples.
settings/env.py
import os
# Quick-start development settings - unsuitable for production
# See https://docs.djangoproject.com/en/1.6/howto/deployment/checklist/
DEBUG = not 'http/ask.helldude.ru/' in os.path.realpath(__file__)
settings/assets.py
# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/1.6/howto/static-files/
import os
import sys
settings = sys.modules['project.settings']
STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(settings.BASE_DIR, 'static')
STATICFILES_DIRS = (os.path.join(settings.BASE_DIR, "project/static"),)
STATICFILES_FINDERS = (
'django.contrib.staticfiles.finders.FileSystemFinder',
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
'compressor.finders.CompressorFinder',
)
settings_local.py:
import sys
settings = sys.modules['project.settings']
print 'I WAS LOADED KHA KHA KHA'
if settings.DEBUG:
print 'In debug mode'
You can see amazing 'hack' there :-)
I use already defined settings via sys.modules['project.settings'] (where project is common folder for my project applications).
I hope you like this small lifehack for django settings!
rudude.
This is a class I use instead of the default PayPalPaymentsForm in django-paypal.
I wanted to use the Paypal sandbox on my development site and the real Paypal site on my production site. Currently, if you want to output the Paypal form with the sandbox you have to call the sandbox() method on the form, rather than the render() method.
Using this class instead of the default PayPalPaymentsForm, you can just set PAYPAL_DEBUG to True in the settings file and the form will take you through to the sandbox instead. Don't forget to set the sandbox merchant account's business email address as PAYPAL_RECEIVER_EMAIL too.
Use this class to authenticate against Drupal 7 password strings. When importing passwords from Drupal, the database values should be prefixed with "drupal$".
In contrast to the two present solutions, this class also works with passwords which were imported to Drupal 7 (e.g. from Drupal 6 or phpBB) and with passwords with variable iteration numbers. It is possible to use this class for encoding passwords, but due to questionable design decisions in Drupal (like truncating the non-standard base64 encoded hash at 43 characters) I'd recommend to do this this only if you really need to be able to migrate back to Drupal.
It's haystack whoosh backend code which involves stemming for specific language in time of indexing.
2 lines was changed comparing to original whoosh backend (StemmingAnalyzer replaced with LanguageAnalyzer for russian language, list of supported languages: [here](https://bitbucket.org/mchaput/whoosh/raw/default/src/whoosh/lang/snowball/__init__.py) )
Sometimes you just don't want to display every permission django has, you just want a short list showing the permissions for some of your apps (or even django core apps).
GROUP_PERMISSIONS_MODELS must be a list of your app models. Dotted path (in lowercase) required, app name + model *class* name.
Template context processor for delegating other context processors to individual apps.
Useful if all views within an app require common context variables that aren't required by other apps.
Note: must call within __init__() method, so you must do self.fields["field"] = ModelChoiseField(...). This is because I did not use a ModelChoiceIterator.
A subclass of ModelChoiceField which represents the tree level of each node when generating option labels. It's limited to one level of nesting, if you need more, you should consider the django-mptt package.
For example, where a form which used a ModelChoiceField:
category = ModelChoiceField(queryset=Category.objects.all())
...would result in a select with the following options:
---------
Root 1
Root 2
Child 1.1
Child 1.2
Child 2.1
Using a NestedModelChoiceField instead:
category = NestedModelChoiceField(queryset=Category.objects.all(),
related_name='category_set',
parent_field='parent_id',
label_field='title')
...would result in a select with the following options:
Root 1
--- Child 1.1
--- Child 1.2
Root 2
--- Child 2.1