Two template tags (I keep them in an app called "utils") handy for building menus out of flatpages. I only have two levels of hierarchy, and the frontpage is dynamic, so that's what it does. There is some flexibility, however, in that you can change the regex that defines a "root" page.
You can pass it the flatpage object that is normally given to a flatpage template, or you can pass it a string (for any other page).
Deliberatley does not create any markup -- flexibility is key, so it adds the list of root urls or child urls as a name in the current context. You get to pick the name.
Please visit the [GitHub archive](http://wiki.github.com/0sn/nameremoved/flatpages) where i keep this up to date, there's a better explanation and you can see it in use.
** This tag, as shown, can cause problems (infinite recursion being one) if you don't use it correctly. **
Our internal CMS has a pages app similar to Flatpages, and a "chunks" app similar to [django-chunks](http://blog.clintecker.com/2008/jul/6/django-chunks/). Because most of our other apps are template-tag driven (FAQs, job postings, news, events, etc) I wanted a way to be able to write django template code right into a page or chunk's body from within the django admin.
This tag will let you write django template code into, for example, a Flatpage's content and render it with the current context. So if you had a template tag called "get_latest_news" and wanted to add latest news to a flatpage, just enter this in the flatpage's content:
{% get_latest_news 5 as news %}
{% for article in news %}
<li>{{ article.title }}</li>
{% endfor %}
This ability has proven extremely useful to us. Please note this is just a "summary" snippet to illustrate the concept. Use in a production environment should include more robust error checking.
This is a simple helper to make custom permission decorators for Django views.
Perhaps you have an edit_comment view which you want to make sure current user is the owner of:
>def edit_comment(request, comment_id):
>>if request.user == Comment(id=comment_id).user:
>>>... do authorized things ...
>>else:
>>>... do unauthorized things ...
>>...
>>...
In this view, you might do a quick check `if request.user == Comment(id=comment_id).user`, however you now need to duplicate this code all over the place whenever you want to check if a comment is owned by the current user.
Instead, you can use the built in login_required decorator, and your own decorator to do the test:
>@permission
>def user_owns_comment(request, comment_id):
>>return request.user == Comment(id=comment_id)
>
>@login_required
>@user_owns_comment
>def edit(request, comment_id):
>> ...
>> ...
>> ...
The "tester" function will post a message using the messages module built into Django, and redirect the user to the root. It allows access and executes the view if the tester function returns anything that evaluates to True.
Your permission tester should either strictly specify the same arguments as the view, or take additional *args, and **kwargs to prevent syntax errors on extra arguments being passed along.
- view
- decorator
- permission