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.
** DEPRECATED**, use [django-reversetag @ github](http://github.com/ulope/django-reversetag/tree/master) instead.
If you want to be able to use context variables as argument for the "url" template tag this is for you.
Just put this code somwhere where it will be run early (like your app's _ _init_ _.py) and of you go.
Usage:
{% url name_of_view_or_variable arg1 arg2 %}
**NOTE:** This may possibly break your site!
Every view name that is passed to url will be tried to be resolved as a context variable first!
So if there is a variable coincidentally named like one of your views THEN IT WILL BREAK.
So far it works great for me, but keep an eye out for name clashes.
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"),
)
Simple filter that truncates string to specific number of letters. Example usage in template:
`{{ myvariable|truncatestring:20 }}`
if myvariable is "That is my long string", the result will be: "That is my long s...".
Put the code into templatetags/.
**UPDATE**: A more complete example is up on [GitHub](http://github.com/henriklied/django-twitter-oauth/tree/master)
Based around Simon Willison's [Fire Eagle oAuth](http://www.djangosnippets.org/snippets/655/), this will allow you to develop Twitter oAuth applications (…that is – if you're in the closed beta)
I developed this template loader for adding themes support in [gitology](http://www.amitu.com/gitology/). In order to support theming django applications, add this template loader at as the first TEMPLATE_LOADERS settings.py setting.
Anywhere you request base.html, blog/index.html, when the theme is set to "bw", it will look for bw/base.html or bw/blog/index.html files first.
Takes care of both render_to_response() in view or {% load template %} in templates.
Wrote this some time ago when I couldn't find one already completed. Came up in the IRC channel so I decided to post it.
Easy enough to use.
`from ssldecorator import ssl_required`
`@ssl_required`
`def your_view(request):`
` ''' your code here '''`
You can place a variable in your settings.py to change the SSL domain (ie, if you have SSL running on secure.yourdomain.com instead of www.yourdomain.com)..
`SSL_DOMAIN = 'https://secure.yourdomain.com'`
Note: please include a proper URL. If https isn't used, the decorator will add it.
Save this as `smart_if.py` in the `templatetags` folder of one of your apps. Then a simple `{% load smart_if %}` replaces the boring built-in Django `{% if %}` template with the new smart one.
*7 May 2009*: Was asked about whether it handles combination of and/or. It does, added a test to show it. I actually like how Django doesn't let you do this, but I'm not going to confuscate my code for a restriction like this.
*15 June 2009*: Fixed up a bug with boolean precedence (`x or x == 0` was being parsed as `(x or x) == 0` instead of `x or (x == 0)`). Add some extra test cases, including some for invalid cases.
Example Usage in the template:
<p>{{ email|hide_email }}<br />
{{ email|hide_email:"Contact Me" }}<br />
{% hide_email "[email protected]" %}<br />
{% hide_email "[email protected]" "John Smith" %}</p>
{{ text_block|hide_all_emails|safe }}
All hidden emails are rendered as a hyperlink that is protected by
javascript and an email and name that are encoded randomly using a
hex digit or a decimal digit for each character.
Example of how a protected email is rendered:
<noscript>(Javascript must be enabled to see this e-mail address)</noscript>
<script type="text/javascript">// <![CDATA[
document.write('<a href="mai'+'lto:john@example.com">John Smith</a>')
// ]]></script>
Pass in a date and you get a humanized fuzzy date diff; e.g. "2 weeks ago" or "in 5 months".
The date you pass in can be in the past or future (or even the present, for that matter).
The result is rounded, so a date 45 days ago will be "2 months ago", and a date 400 days from now will be "in 1 year".
Usage:
* `{{ my_date|date_diff }}` will give you a date_diff between `my_date` and `datetime.date.today()`
* `{{ my_date|date_diff:another_date }}` will give you a date_diff between `my_date` and `another_date`
Make sure to install this as a template tag and call `{% load date_diff %}` in your template; see the [custom template tag docs](http://docs.djangoproject.com/en/dev/howto/custom-template-tags/) if you don't know how to do that.
Adapted from #848 to basically copy the reply tag and create it again as a hash tag filter.
Kudos to ryanberg, not me.
will be in use on my website soon (www.dougalmatthews.com) for a demo.
"Thus, if a LOGGER is configured inside settings.py, we use that. Otherwise, we just use vanilla logging functions with the global logging configuration. Nice and sweet."
Naturally, the logger can be anything described [here](http://docs.python.org/library/logging.html), I'm just using the RotatingFileHandler as an example because that's what I was using in my project.
Full write up+shamless plug [here](http://mihasya.com/blog/?p=237)
This is a function wrapping the code from [example](http://docs.djangoproject.com/en/dev/topics/pagination/#using-paginator-in-a-view) from django docs.
The required parameters are: `request` which is a `Request` object from a view, and `objects` - a list of objects to paginate.
You may want to tune number of items per page by specifying `count` and the name of a GET parameter through `param_name`
To use it in your view just wrap the paginated object into a function for example:
def someview(request):
articles = Article.objects.all()
... some other logics ...
return render_to_response(template, {'articles': paginate(request, articles)}
This is a simple modification to the standard transaction.commit_on_success decorator that is aware of existing transactions. If a managed transaction is already active then the wrapped function is called directly, assuming the active transaction will clean up as appropriate. Otherwise, a standard commit_on_success is performed.
I'm using this to wrap the save() method of models that manipulate other related models on save, e.g:
@nested_commit_on_success
def save(self):
super(MyClass,self).save()
for m in other_models:
self.fix_up_other_model(m)
m.save()