The simplest way of displaying a "details" table about any model, is to show a ModelFrom with all fields readonly or (selects) disabled. Also, the labels are preferably translatable, not just capitalized names of the column tables in your models. So the constructor translates the field labels as well.
This snippet shows how to add additional parameters to the queryset of a ModelChoiceField, enabling you to for instance filter the query.
This is a little snippet that you can use to make your Django newforms dynamic at runtime. You can define an arbitrary number of fields of the form without loosing newforms capibilites. You can render the form dynamically be "misusing" the "help_text" attribute of the form fields (Every form field allows the definition of this attribute). This way you can search for changes in the help_text of every field and render the form accordingly. The form itself is dynamically defined in the view. The form state can be saved in a Django Session Variable (specifically for Linux users with a process-based Apache Server), so that you can rebuild and verify a submitted form.
** Allows to get field value in the template. ** First load template tag. Then {% field_value form.field %}
The result maybe: http://localhost/test/ And for request.path, it will not include the domain field(http://localhost).
I recently worked on an application, where I had to provide a way for users to search for objects based on user-defined properties attached to these objects. I decided to model the search form using a formset, and I thought it'd be a good idea to allow users dynamically add and remove search criteria. The script (dynamic-formset.js) should be re-usable as-is: 1. Include it in your template (don't forget to include jquery.js first!). 2. Apply the 'dynamic-form' class to the container for each form instance (in this example, the 'tr'). 3. Handle the 'click' event for your `add` and `delete` buttons. Call the `addForm` and `deleteForm` functions respectively, passing each function a reference to the button raising the event, and the formset prefix. That's about it. In your view, you can instantiate the formset, and access your forms as usual.
If you want to test for trivial error in your add and changelist admin views, use this snippet. Save the snippet in admintests.py and put it anywhere in your pythonpath. Put this code in your tests.py: from django.test import TestCase from admintest import adminviews_test class TestAdminViews(TestCase): def test_admin_views(self): adminviews_test(self)
This works with `Django 1.0.0` and later. It sets the `request.urlconf` variable to an alternate urlconf, if there's a match to the hostname in `settings.MULTIHOST_URLCONF_MAP`
This code is taken from a [Stack Overflow answer by Will Hardy](http://stackoverflow.com/questions/3715550/creating-a-list-on-the-fly-in-a-django-template/3715794#3715794). Usage: `{% collect var1 var2 'foo' 'bar' 5 as some_list %}`. Sometimes one wishes to create a list on the fly within a template. Perhaps a collection needs to be passed to a template filter, but the collection cannot be created in the view since the values of one or more of its items are set in the template. A contrived example: {% with 5 as max %}{% with posts|length as len %} {% for post in posts %} {% if forloop.counter <= max %} {% include 'excerpt.dhtml' %} {% endif %} {% endfor %} {% collect len max as limits %} <p>Displaying {{ limits|minimum }} of {{ len }} post{{ posts|pluralize }}.</p> {% endwith %}{% endwith %} The final line will state how many posts are displayed: something like "5 of 24" or "2 of 2". This particular problem can be solved in a number of other ways, some of which are more appropriate. Having a template tag that can create lists on the fly is potentially useful in quite a few situations, though. I don't know whether this need is common enough to warrant being in the core. If something like this is to be included one day, it'd be much nicer to overload the `with` tag than to introduce a new tag. `{% with var1 var2 var3 as some_list %}` reads well.
As I was unable to find good examples to render a Form with two or more inlineformsets. Therefor I have posted this to Django snippets. This code is little different from another snippet with a Form with one InlineFormSet (the prefixes are necessary in this situation). The example shows a person's data together with two inline formsets (phonenumbers and addresses) for a person. You can add, update and delete from this form.
If you use django admin interface and have added an admin page for a model, django gives out-of-box search functionality in the model fields or foreignkey fields. One thing it doesn't support is searching in child models. For example you have created an admin page for Student model and there is model for courses which stores one or more courses taken by students and if you want to search by course name on the student page to see which students took a particular course. Django doesn't let you do that. I have written a small utility which will let you do that. Just copy the snippet in a file and then inherit from the ChildSearchAdmin instead of ModelAdmin and then you can specify which model/fields you want it to search on. The syntax is: **child_searches = [(ChildModel, 'field_to_search_on', 'foreign_key_field_in_child_model'),..] Example: class StudentAdmin(ChildSearchAdmin): child_searches = [(StudentCourse, 'course', 'student')]
I was just playing around with Django 1.3 and came across the new 'with' addition to the include tag. I thought this was a super elegant way to implement a DRY tab menu without having to move menu code into the views. Enjoy!
Originally based on: [http://djangosnippets.org/snippets/1872/](http://djangosnippets.org/snippets/1872/) The way the original snippet formatted sql didn't work for mysql properly so I taught it to use the sqlparse python module. Now it looks like this when settings.DEBUG=True: SQL executed: SELECT "django_session"."session_key", "django_session"."session_data", "django_session"."expire_date" FROM "django_session" WHERE ("django_session"."session_key" = d326108d313a2e5c5fb417364b005ab9 AND "django_session"."expire_date" > 2011-04-08 14:54:13.969881) took 0.001 seconds SELECT "auth_user"."id", "auth_user"."username", "auth_user"."first_name", "auth_user"."last_name", "auth_user"."email", "auth_user"."password", "auth_user"."is_staff", "auth_user"."is_active", "auth_user"."is_superuser", "auth_user"."last_login", "auth_user"."date_joined" FROM "auth_user" WHERE "auth_user"."id" = 2 took 0.000 seconds Additionally, this middlware is enabled conditionally based upon the url query string "debug". You can enable it for a single request by appending: ?debug=true to the url.
This is a function to take a Q object and construct a function which returns a boolean. This lets you use the exact same filter syntax that Django's managers use and apply it inside list comprehensions, or to non-persistent objects, or to objects of different types with the same attribute names.
As title