add JSONRequestMiddleware to your enabled middleware in Django settings. Now, in your view functions, you can call request.json() to get a parsed json body! json is consumed lazily, and cached.
In the last few days I spent a lot of time trying to find a library or repository of some kind that could help me generate the required DAYLIGHT and STANDARD components of ical VTIMEZONE blocks. Since I couldn't find anything, I cobbled together this snippet to poke around in pytz timezone information and output the bare minimum I needed to make my ICS files compliant and useful (DST transitions for this year and the next). I promise it's (superficially) tested against "real" ICS files, but that's all. UPDATE: Thanks to @ariannedee for a much improved version (see comment for details)
This method will return an inline formset class that validates values across the given field are unique among all forms. For instance: ApprovedUserFormSet = inlineformset_factory(Request, ApprovedUser, formset=unique_field_formset('email'), form=ApprovedUserForm) Will make sure all ApprovedUser objects created for the Request have unique "email" fields.
Django's built in authentication system requires the username to be alpha-numeric only. Therefore, email addresses are invalid. However, in many cases, you would like to use an email address as the username. This snippet allows you to do so. It has the added benefit that if you want to continue using the regular username format, you can do that too. It's the best of both worlds! To make sure propoer credit is given, this code is modified from a django group posting from Vasily Sulatskov. To use this file, save it in your project as something like: email-auth.py Then, add the following lines to your settings.py file: AUTHENTICATION_BACKENDS = ( 'yourproject.email-auth.EmailBackend', ) You can see a full implementation [here] (http://www.satchmoproject.com/trac/browser/satchmo/trunk/satchmo)
This snippet adds simple partial support to your templates. You can pass data to the partial, and use it as you would in a regular template. It is different from Django's `{% include %}`, because it allows you to pass a custom variable (context), instead of reusing the same context for the included template. This decouples the templates from each other and allows for their greater reuse. The attached code needs to go into `templatetags` folder underneath your project. The usage is pretty simple - `{% load ... %}` the tag library, and use `{% partial_template template-name data %}` in your template. This will result in template passed as **template-name** to be loaded from **partials** folder. The **.html** extension will be appended to the file name. The file has to be in one of template paths accessible to the loader) and rendered with **data** as its context. The data is available in the template as an `item` context variable. You can find more information in the [relevant Django documentation](http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#howto-custom-template-tags)
A set of classes that enables fast and flexible generation of HTML tables from columns definitions and datasets. With classes arguments, it is easy to style it with bootstrap for example.
Creates a model serializer class on the fly, just taking the model (class) as its argument. My use case: When importing data from spreadsheets, the DRF serializers are an easy way to create model instances from a dictionary. This function saves me from creating a custom serializer each time I add a new importer. Using `__all__` is dangerous ;-)
nothing
Sometimes a plain-text help-text isn't sufficient, and it's handy to be able to add links to pages, documentation or external websites. This javascript snippet can be added to your page, in combination with adding a class to your help text in your template. This assumes you're using jQuery on your website. Field template snippet: ``` {% if field.help_text %}<p class="help-text">{{ field.help_text }}</p>{% endif %} ``` On document ready, this will convert the markdown-style links into anchor tags, allowing you to have richer help text for your users
A more simple version of [https://djangosnippets.org/snippets/1688/](https://djangosnippets.org/snippets/1688/), inheriting from `SelectDateWidget`, overriding only the necessarily. **Usage example:** **In models.py:** from django.db import models from django.utils.translation import gettext_lazy as _ class MyModel(models.Model): start = models.DateField( _("Start date"), ) end = models.DateField( _("End date"), ) class Meta: verbose_name = _("My model") **In forms.py:** from django import forms from .models import MyModel from .widgets import MonthYearWidget class MyModelForm(forms.ModelForm): class Meta: model = MyModel exclude = [] widgets = { "start": MonthYearWidget(), "end": MonthYearWidget(last_day=True), } **kwargs:** - *last_day :* if set to `True`, returns the last day of the month in the generated date.
As you can see, if you using django-rest-framework, you will found many different response format. This middleware to solve all of these problems with Standard API Response. All HTTP Response status stored into json response, not in HTTP Status (because mobile application, like android can't fetch the response body when HTTP Status >= 400).
A simple jQuery javascript that collapses all stacked inline rows for better handling of large inline fieldsets. It also adds "Show"/"Hide"-buttons for showing/hiding each row, which could be customized and styled using css. **Usage (see below for example):** Include the javascript on your admin page, together with jQuery, and it'll automatically affect all stacked inlines. **Works with** Django 3.1.4 (Might work with other versions with or without adjustments, but not tested) **Use example:** *admin.py:* class DateInline(admin.StackedInline): model = Date extra = 10 class EventAdmin(admin.ModelAdmin): inlines = [DateInline] class Media: js = ['js/collapsed-stacked-inlines.js'] admin.site.register(Event, EventAdmin)
Stuff
Piggybacks on the pagination-related template context variables provided by the `object_list` generic view, adding extra context variables for use in displaying links for a given number of pages adjacent to the current page and determining if the first and last pages are included in the displayed links. Also makes it easy to implement consistent paging all over your site by implementing your pagination controls in a single place - paginator.html. Optionally accepts a single argument to specify the number of page links adjacent to the current page to be displayed. Usage: `{% paginator %}` `{% paginator 5 %}`
Usage: {% load helper_tags %} {% get_available_languages as languages %} {% for lang_code, lang_name in languages %} <link rel="alternate" hreflang="{{ lang_code }}" href="{% change_lang lang_code %}"> {% endfor %}