simple search with Q object you just pass a list of fields and the search string then it will come up with a object to use in a filter. This snippet is thanks to Julien Phalip at [julienphalip.com](http://www.julienphalip.com/blog/2008/08/16/adding-search-django-site-snap/)
Veritabanına eklenmiş tüm models isimleri Get all models name kullanımı / usage: {% load moduller %} {% moduller %}
Html içinde split ile kesme Kesme işleminden sonra kaçıncı bloğun okunacağını düzeltebilme {% kes request.path "/" 3 4 %} gelenveri.split("/")[3:4]
A shortcut to render templates with RequestContext
Version of ManyToManyField that can be set even if it relies on a intermediary model.
Sometimes the related objects needs that the main object exists in order to edit and save them properly. There are two main solutions: override the ModelAdmin.add_view() view or remove the inlines only from the add view page (and not from the change page). The former requires a lot of coding, the latter it's impossible without patching Django because the inlines are not dynamic. **This simple solution hides the inline formsets only from the add page, and not from the change page.** Adding an "if" structure it is possible to choose the inlines to use. Example use case: when a related inline model have to save a file to a path that needs the ID key of the main model, this solution prevent the user to use the related inline model until the model it's saved. Tested on Django-1.4, should work since Django-1.2.
Example: admin.site.register(YourCoolModel, CustomModelAdmin)
showing all the errors at the top of the page
Django does not have a clean, built-in mechanism to separate GET and POST implementations. This simple decorator provides this behavior. Django does provide an alternate way using class-based views, but defining class for each of your view functions may be an overkill. You can name the get and post functions anything you wish, but you need to make sure they are returned in the same order (get first and then post). Example usage: @formview def edit(request, id): form = EditForm(id, request.POST or None) def get(): return render(request, 'edit.html', {'form' : form}) def post(): if form.is_valid(): form.save(id) return redirect('list') return get, post
Use this decorator on a function that returns a dict to get a JSON view, with error handling. Features: * response always includes a 'result' attribute ('ok' by default) * catches all errors and mails the admins * always returns JSON even on errors
Here's the python code to produce an admin related widget with the edit and delete link also. * [RelatedFieldWidgetWrapper](http://djangosnippets.org/snippets/2562) * [related-widget-wrapper.html](http://djangosnippets.org/snippets/2563) * [related-widget-wrapper.js](http://djangosnippets.org/snippets/2564) * [RelatedWidgetWrapperAdmin](http://djangosnippets.org/snippets/2565)
After using Zope3/Grok for a little, I wondered how hard it would be to implement views as classes in Django, in a similar vain to how it's done in Grok. I came up with something rather simple but effective. It may be more appropriate if you use a template engine other than Django Templates, which allows you to call functions with arguments, but it's still useful none-the-less to encapsulate functions in a class. You could, for example, extend View to be JinjaView, just replacing render_template(). A nice extension, I imagine, would be to automatically figure out the template name as well as the path prefix for it (since you probably want it to be found under packagename/templatename.html).
SELECT FOR UPDATE, which does row-level locking in the database, was added by Django only in version 1.4. This snippet emulates that feature in older versions of Django. Tested in Django 1.2, but should work in newer versions as well. select_related is removed because it causes errors when used with RawQuerySet.
Jinja2, while a great replacement for Django templates, is not a drop-in replacement for it. I wanted to use Photologue with my Jinja templates, but because Photologue uses Django generics, so I decided to see if I could use Jinja2 with generics, and then only modify the templates. It was a bit of work, but I seem to have done it. Django generics can take template_loader as an option, so if you have the same interface, things should just work. The template must accept RequestContext as an argument to render(), so here we subclass jinja2.Template and when it receives Django's RequestContext object, it creates a flat dictionary from it, which jinja2 can work with.
An old snippet I made in my first django project. Nowadays I code menus in HTML and just use the perms proxy: https://docs.djangoproject.com/en/1.0/topics/auth/#id6 Credits, (awsome persons that helped me getting it to work efficiently and for free): * Yhg1s and waveform from #python@freenode * zendak from #django@freenode Thank you!