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
jQuery dataTables is a fantastic and powerful client-side plugin, which has many capabilities.
There are many libraries out there that easily integrate it with django with little to no effort. However, they provide everything out of the box, which isn't always the most flexible solution. I also think beginners have a lot to learn from not using already created tools.
So, finding the general examples out there lacking, I though I'd hatch out a quick example of how to very basically integrate the two.
I supply two lists at the top which define how to order the fields and which are searchable (quite similar to the one defined in the admin site) and later everything is figured from there.
Of course, for a little more complex implementation (say using a method instead of a field) this will not work (since getattr doesn't automatically call a function if it is a function), but this snippet isn't supposed to provide everything but a very basic usage example, which can be very quickly expended in any way needed.
Anyway, this snippet should work on all django versions and all dataTables versions without a hitch.
last note- I use `cStringIO` with `json.dump` out of good personal experience with that settings, though it might not be the best way to serialize the data.
Good luck, share use and enjoy, ~yuvi