extending generic_markup.apply_markup
I wanted to keep the flexibility of generic_markup but add my own filtering option for apply_markup. So I created app/templatetags/mm_markup.py.
- markup
- markdown
- templatetags
I wanted to keep the flexibility of generic_markup but add my own filtering option for apply_markup. So I created app/templatetags/mm_markup.py.
Sometimes running a test suite can take a long time. This can get especially annoying when you see a failure or error, but have to wait for all the remaining tests to run before you can see the relevant stack traces. Pressing ctrl+c to interrupt the tests does not work; the KeyboardInterrupt exception does not get caught and only a stack trace irrelevant to your tests is produced. This behavior can be altered through overriding the testcase's `run` method and catching the exception yourself. Now you can stop the tests whenever you want to and still see what is wrong with your tests.
Detect blog platform. As we all known, there are so many blog platform in the wild, e.g. Blogger.com, WordPress, LiveJournal, Movable Type etc. This little snippet could guess the blog platform according a url. Dependency: 1. pycurl 2. BeautifulSoup
Helps create menus that modify URL query parameters. Create the Menu object in your view and put it in the template context.
`{% tablify questions name response 8 %}` Will generate a table structure of a list, ensuring that a set number of columns is not exceeded. It takes 4 arguments: *Context Variable *Cell Header Attribute *Cell Data Attribute *Max Number of Columns The code will loop through the given variable, creating th and td elements for each item. It will create a new tr when the max number of columns is exceeded.
Sometimes I would like to test a codesnippet without a complete django environment. Here is a small "local test script" you can use for this ;)
From [here](http://gacha.id.lv/blog/26/01/2007/django-autocompletefield/) with litle improvements. [More about Script.aculo.us and Django](http://wiki.script.aculo.us/scriptaculous/show/IntegrationWithDjango)
This adds a checkbox for each object and three buttons to a model's change list: 1. **Delete selected:** deletes the selected objects 2. **Delete shown: ** deletes all the visible objects. For example, if you perform a search or in any way filter the list, this button deletes only objects that were filtered. 3. **Delete all: ** Deletes all instances of the model, including those not shown (if looking at a filtered list). The deletes perform no confirmation -- once you hit the buttons the models are **gone**, so maybe don't use (or add a confirmation screen) for really sensitive stuff. * uses django oldforms-admin (ie 0.96) * works fine if you include a search_fields list in the Admin class * code for the view could probably be refactored a bit :)
There are a lot of reasons why you should not do this. But nevertheless it might be useful in certain situations. If your database does not change and you want to use validators etc you better use inspectdb from django-admin.py
This snippet provides a form_for_model and form_for_instance function which create newforms that respect the unique and unique_together constraints defined in the model. One thing about the coding style in this code snippet: Classes are capitalized even if they're passed as arguments. Thus "Model" is a model class while "model" is a model instance.
I wanted to mark rows with an erroneous input with 'class="error"' and move the errorlist below the input tag so I wrote a NormalRowFormatter which behaves like a format string by overwriting \_\_mod\_\_. Examples: class MyForm(PrettyBaseForm, forms.Form): # add your fields here SomethingForm = form_for_model(Something, form=PrettyBaseForm)
As an alternative to using forms rendered with the default hard-coded html, this factory function will take a template name as argument, and return a Form class based on django.newforms.BaseForm, which will render each form field using the supplied template. As an example, I'm using this class as follows in one project (slightly edited with respect to project and app names): # Get a form class which renders fields using a given template CustomForm = proj.utils.makeTemplatedForm(template="app/formfield.html") # Get base form class for the details model BaseAppForm = forms.form_for_model(models.AppDetail, form=CustomForm) using this template: {% if errors %} <ul class="errorlist"> {% for error in errors %} <li>{{ error }}</li> {% endfor %} </ul> {% endif %} {% if field.required %}<span class="required">*</span>{% endif %}{{ text }} {{ help_text }}
A handy ANSI-colored logging mechanism to display the SQL queries and times in the terminal when using django-admin.py runserver. DEBUG mode must be true for this to work.
This was a much better way of incrementing variables that only changed a small amount in name. deltab in #python also said I could have used tuples, but I'm not familiar with them yet, so I added this to a list of things to look into.
when running a console script to access django or your models, you need to setup django environment properly and that is very annoying if you have quite a few scripts. this script can be used as a wrapper just like the manage.py. put it in your project root and type this: python run.py myproj.appname.filename.functionname [arguments] and define your function as def functionname(argv[]): ...