Okay - so I came across a really annoying problem earlier, where I wasn't able to *easily* load a formwizard as a segment into an existing view, and wrap it using my existing site template layouts. This was *REALLY* annoying. Especially since I wanted to keep as much of a 'overall' templating and application logic in the views.py (and just leave the forms.py to handle the form and its own templating for the form pages)
I spent about 2 hours trying to make this as conventional as possible, and finally came up with a solution. The result is something which looks as similar to the usual functionality. This also meant that there is seperation between form styling and overall site styling, so your forms can be used between multiple sites, and if your overall site template uses extends, then the context support keeps this nicely in order.
This also allows you to initialise the formwizard in a nicer way.. Of course, in each file, you'll need to import the necessary bits (like importing the testform from the view etc)
Decorator that stores the `request.path` URL in a session variable to be used later, e.g. in a "Continue Shopping" link on a cart page. Wrap and view that you want to be able to link back to easily. When those views are called, it updates the session with the current `request.path` value. This can be pulled back out of the session whenever you need to provide a link back from whence the user came.
If you are an admin of a django site and many times it feels to visualize or experience how a normal website user actually sees different pages of your website. So to get this done, we create a normal user (just for testing purposes) and check the same, which is good. But sometimes we need to actually login as the same person to resolve a issue or to trace a particular exception which only one user or a specific set of users are experiencing.
Usage:login_using_email(request, "[email protected]")
I have mentioned only the helper or core method which is responsible for the actual user "logging-in" simulation. Proper view permissions(remember I mentioned only admins should use this) can be wrapped around it. Any thoughts on improving it? Always invited....
Public Clone Url: [git://gist.github.com/242439.git](git://gist.github.com/242439.git)
It is often convenient to be able to specify form field defaults via GET parameters, such as /contact-us/?reason=Sales (where "reason" is the name of a form field for which we want a default value of "Sales"). This snippet shows how to set a form's initial field values from matching GET parameters while safely ignoring unexpected parameters.
you have a multilingual site and need to change languages in admin. Previously this was easy in the site itself and more difficult in admin. Now it is dead easy. Set up your languages in settings.py. Make a directory called 'admin' in your templates directory, copy ~/django/contrib/admin/templates/base.html to that directory. Add the following code (below breadcrumbs is a good place)
this will give you a switcher for all installed languages. You would need to refresh the browser on changing the language.
Sometimes it is useful to have a ChoiceField which calculates its choices at runtime, when a new instance of a form containing it, is generated. And this is what `LazyChoiceField` does.
The `choices` argument must be an *iterable* as for `ChoiceField`.
**Usage example**
from django import forms
DynamicApplicationList = []
class MyForm(forms.Form):
dynamic_choice = LazyChoiceField(choices = DynamicApplicationList)
`DynamicApplicationList` can now be updated dynamically.
This templatetag let's you output a form with select boxes instead of the ul's for filters.
Uses some hacks to get the param names out of query strings.
This would be a lot easier if filterspecs defined params instead of query strings
(if filter tag would handle the encoding)
runserver with extra development tools:
1. interactive debugger that pops up automatically if an exception occurs, courtesy of [Werkzeug](http://werkzeug.pocoo.org/documentation/dev/debug.html#using-the-debugger)
2. logging of print statements directly into HTML (div float), courtesy of [Paste](http://pythonpaste.org/modules/debug.prints.html).
Credits: [piranha.org.ua](http://piranha.org.ua/)
You have to put this code in your *searchengines* Firefox folder in a file called **djangosnippets.xml**
After restarting Firefox, you will be able to seek DjangoSnippets very easily.
I also create a favicon.ico since djangosnippets.org didn't have one ...
Path example : /usr/lib/iceweasel/searchplugins/djangosnippets.xml
Active class for navigation link
{% navclass default current url %}
First argument is the default class and second is the current class
Third argument is the url name(s) of the page
example: <a class="{% navclass leftnav curentnav name1,name2 %}" href="/about/">
In Django humanize naturalday filter, you could not get the time part since a programming issue, If you apply it like:
{% load humanize %}
{{ response.date_submitted|naturalday:"Y/n/j H:i" }}
You can get 'today', 'yesterday', 'tomorrow' or empty, but you can not get such as '2009/9/10 11:56'
So I change it like above code. Now you can get 'today', 'yesterday', 'tomorrow' or '2009/9/10 11:56'
This template filter, "jumptime" will find any timecodes in a chunk of text and convert them to links that can be used to jump a video player to that point. E.g., If there is the string "3:05", it will be converted into a link that can be used to jump to that point. This is similar to what youtube does.
For information on how to implement, see Django's [custom template tag information](http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#howto-custom-template-tags).
You'd use this with some javascript like this:
`jQuery(document).ready(function(){
jQuery('a.jumpToTime').bind('click',function(){
player.sendEvent('PLAY');
player.sendEvent('SEEK', jQuery(this).attr('value'));
});
});`
I recently had a need to build an iTunes style filtered search -- a user can add/subtract any number of filters whereby the are offered selects for fields they want to search, what type of search they wish to perform on that field (i.e., equals, contains, etc.), and then enter a value to search. Finally, they are provided the option to search all or any of the created filters.
To keep things simple, I created this dynamic query builder. It takes a Model, plus lists of fields, types, values, and the chosen operator (and/or). Then, it constructs actual Q objects for each, performing a small sanity check to ensure a blank value has not been passed in.
In the end, it returns either a filtered QuerySet or an empty result set to ensure that we can at least provide a message back to the user if nothing comes of trying to build the query.
One would use it like so:
results = dynamic_query(ModelName, fields_list, types_list, values_list, operator)
if results:
# do something
else:
# do something else
You're looking at the most-bookmarked snippets on the site; if you'd like to help useful snippets show up here, sign up for an account and you'll get your own bookmarks list.