Based on our [first version of soaplib service integration](http://www.djangosnippets.org/snippets/979/), this second one adds Basic Auth with credentials specified in settings. It can be tested with [django soaplib test cliente](http://www.djangosnippets.org/snippets/1406/)
This code *monkey patches* soaplib client to allow the usage of django test client for local web service testing (without a running server). It adds *basic* authentication.
If you app defines some URLs with a name, and you want to overwrite this at project level with a different view you can use this snippet. You only need to change on line in the application code (the import statement).
**Update:** Never mind. See [dc's comment](http://www.djangosnippets.org/snippets/1391/#c1763) below for a much easier way to do this. I recently had to write a template for a paginated view which displayed a serial number for each `object` in the `object_list`. I normally use `forloop.counter` for general purpose serial numbers. However this did not work with paginated views as the counter gets reset in each page. This caused the serial numbers to go from 1 to #-of-results-in-the-page and then repeat. **Assumptions:** The `adjust_for_pagination` filter adjusts the value of `forloop.counter` based on the current page. `Page` and `is_paginated` variables are expected to be present in the context. These should respectively denote the current page number (1 based) and if the results are paginated. `RESULTS_PER_PAGE` is currently taken from the settings file. I couldn't think of a way to pass this value also from the template.
Simple logger, stores all query parameter and post parameters for each query.
Lets you easily create loggers.
A helper.
This is a decorator that logs function arguments, return object and time taken for execution as well as any exception that might have been raised by the function. Useful for debug logging.
I didn't really like the current state of iPhone/Mobile redirect middleware mainly because I wanted something that was closer to twitters use case. So I came up with this. I don't think it a great snippet and I will probably fix it in the near future. But it works.
Some of this is modified from [http://www.djangosnippets.org/snippets/1062/](http://www.djangosnippets.org/snippets/1062/)
This is heavily inspired by [http://code.google.com/p/smorgasbord/](http://code.google.com/p/smorgasbord/). But that couldn't reuse an existing jinja2 Environment, nor set filters on the Environment it created. This code assumes that you have `env` declared previously in the file as your Jinja2 Environment instance. In `settings.py`, you should set KEEP_DJANGO_TEMPLATES = ( '/django/contrib/', ) so that your Django admin still works. You can also set any other places that you do want to use Django templates there.
Middleware for implementing "hours of operation" for a website. In use (as configured here) on http://ianab.com/.
There are probably ways to improve the implementation, but this was something I came up with when I wanted to change the default size of all of my CharField admin fields. Now all I have to do in my ModelAdmin class is: form = get_admin_form(model) or subclass BaseAdminForm if I need extra validation or more widget customization for an individual admin form.
http://steven.bitsetters.com/articles/2009/03/09/testing-email-registration-flows-in-django/ Testing email registration flows is typically a pain. Most of the time I just want to sign up with a test user, get the email link and finish the flow. I also want to be able to automate the whole process without having to write some SMTP code to check some mail box for the email. The best way I’ve found to do this is just to write out your emails to some file instead of actually sending them via SMTP when your testing. Below is some code to do just that. I’ve also created a Django management script that will open the last email sent out from your application, find the first link in it and open it in your web browser. Quite handy for following email registration links without logging into your email and clicking on them manually.
This snippet is working code, however it is not intended for proper use, rather to garner comment on an alternative style of view - using a class for views, rather than a function. While working with views, I've often felt that the traditional django code layout splits concerns in an unnatural fashion. The parameters for a view must be maintained in both the urls file as well as the view for example, and there is no neat way of grouping multiple accessor for a REST resource. This 'shim' code aims to propose an alternative architecture, that is interchangeable with the existing system. Rather than include a tuple of urls, instead a list of classes is provided. Each class models a resource, or page. Page objects have a url property and name property, so it is therefor trivial to reconstruct the url tuple from the class, but allow more simplicity and structure in relating the methods of the resource. You may notice that this structure closely follows the architecture of the web.py framework - this syntax did indeed play a part in the concept for such a structure. While this paradigm may not be suitable in all situations, I believe it promotes a simpler, more encapsulated views architecture. Any comments and feedback are welcomed. Example usage (untested, sorry): class Homepage(Page): def get(request): return HttpResponse("Hello World") urlpatterns = patterns('', Homepage, url('^existing$', existing.view.function, name = "foo"), )