The newforms package allows you to simply add new field types to your forms.
This snippet shows the addition of a new type of field, to make sure the user enters sensible currency values (either with no decimal, or two-decimal places), and a custom widget to make sure that the value is displayed correctly when the user sees the form.
The CurrencyInput widget simply tries to display the current value in floating point 2-decimal places format (and gives up if it can't). The CurrencyField makes sure that the input value matches a regular expression, and when it is asked to clean the value it converts it to a float.
The regex here limits the amount to 99,999.99 or less. This is within the bounds of accuracy of python's float value. If you want to use truly huge values for the amount, then you'll face problems with the floating point not being able to represent the values you enter, and so the conversion to floating point in the field will fail. In this case it would be better to use python longs, and used a fixed point interpretation.
- newforms
- validation
- currency
- form
- widgets
Changes **all slugify calls** to support translat automatically, behind the scenes. Using this one doesn't have to change any models or code to make it work everywhere.
Create new project, I call it myself *autoslugifytranslat*, and add the following to project's `__init__.py` file. It will automatically add translat slugify support for all default slugify calls.
This script is depending on the fact that slugify function in Django is always in *django.template.defaultfilters.slugify*.
**Note:** The snippet is supposed to have "ä","Ä" and "ö","Ö" in the `char_translat` list, but djangosnippets does not let me put ä's and ö's to the code part!
- i18n
- slugify
- translat
- internal
This code assumes a) that you are using PostgreSQL with PostGIS and b) that the geometry column in your model's table is populated with points, no other type of geometry.
It also returns a list instead of a QuerySet, because it was simpler to sort by distance from the given point and return that distance as part of the payload than to muck around with QuerySet. So bear in mind that any additional filtering, excluding, &c., is outside the scope of this code.
'Distance' is in the units of whatever spatial reference system you define, however if you do not intervene degrees decimal is used by default (SRID 4326, to be exact).
To get distance in units a little easier to work with, use a spatial ref close to your domain set: in my case, SRID 26971 defines a projection centered around Illinois, in meters. YMMV.
- gis
- postgis
- geography
- geometry
- nearby
- nearest
- distance
This a small but very handy view that gives you a convenient direct access to your templates.
Now suppose you saved the snippet under `misc.py`, it's critical to add this snippet (or a similar one, once you get the idea) to your `urls.py`:
if settings.DEBUG:
# Direct Templates
urlpatterns += patterns('misc',
(r'^template/(?P<path>.*)$', 'direct_to_template', {'template': '%(path)s'}),
)
Now you are able to access any of your templates, in different directories by specifying their path after `template/`. e.g., http://example.com/template/news/index.html
Of course you can change it as you want, you can also add other values to the dict argument, the only required key is `'template'`. The whole dict is made available in the template as a context.
All GET parameters are made available in the template too. So `http://example.com/template/news/index.html?title=Testing Title` will make the `{{ title }}` var available in your template. So you can substitute basic variables quickly.
This is was inspired by [django.views.generic.simple.direct_to_template](http://www.djangoproject.com/documentation/generic_views/#django-views-generic-simple-direct-to-template)