Logging and statistic middleware
Reviewing some statistic-middleware-classes I think you might need one wich is working correct and high-performant. Please comment it and have fun with it!
- middleware
- stats
- logging
- statistic
- user-activities
Reviewing some statistic-middleware-classes I think you might need one wich is working correct and high-performant. Please comment it and have fun with it!
This middleware replaces the behavior of the APPEND_SLASH setting in the CommonMiddleware. Please set `APPEND_SLASH = False` and `SMART_APPEND_SLASH = True` if you are going to use this middleware. In your URL patterns, omit the trailing slash for URLs you want accessible without the slash. Include the slash for those URLs you wish to be automatically redirected from an URL with the slash missing. If a URL pattern exists both with and without a slash, they are treated as two distinct URLs and no redirection is done. Example urlpatterns = patterns('some_site.some_app.views', (r'^test/no_append$','test_no_append'), (r'^test/append/$','test_append'), (r'^test/distinct_url$', 'view_one'), (r'^test/distinct_url/$', 'view_two'), ) Behavior of URLs against the above patterns with SMART_APPEND_SLASH enabled: http://some_site/test/no_append → test_no_append() http://some_site/test/no_append/ → 404 http://some_site/test/append → http://some_site/test/append/ http://some_site/test/append/ → test_append() http://some_site/test/distinct_url → view_one() http://some_site/test/distinct_url/ → view_two() This module is also available [in our SVN repository](http://trac.ambitone.com/ambidjangolib/browser/trunk/middleware/common.py).
I like to keep all local settings files in my versioning repository. The way I differentiate between them is by querying the hostname of the local machine. I've got a host_settings folder with local settings files. Notice that the local settings file names go by a convention where '.' is replaced with underscores. Example: host_settings/local_machine_tld.py
This example shows how you can easily limit the objects in the admin by specifying which Manager the admin should use. I haven't seen this documented anywhere (perhaps I've missed it), but it's proven extremely useful to me. The example here will limit objects to those that are attached to the current Site, but you can use any Manager you want (for example, a Manager that shows only published Articles). Finally -- not that I'm suggesting this -- but you *could* combine this with the ThreadLocals trick to show only objects that have been created by that user.
template tag to format two dates as a date range
It's a template tag used to create boxes with nested divs (useful to keep the templates DRY). For example: {% menubox titlevar %} Content here {% endmenubox %} will generate the html with the nested divs div class=box div class=box-outer div class=box-inner Headline Content /div /div /div [more detail on this blog post](http://pedro.valelima.com/blog/2007/sep/26/boxes-template-tags/)
By default extend tag don't cache parents template. This is extend tag with patch. Workaround for bug: http://code.djangoproject.com/ticket/6586
I had a need to colorize the nicks for the new DjangoBot Logger. Instead of managing a collection of names and corresponding colors we decided it would be more simple to just "hash" the nickname using a colorize filter. This causes the same nickname to always appear in the same color.
Many models are tightly coupled to the default Django `User` model (`django.contrib.auth.models.User`). Sometimes this user model just doesn't fit everyone's needs. By using `UserForeignKey` it is possible to make the `User` model configurable, encouraging loose coupling. Additionally, this can help to prevent circular imports between `User` and another model. Use it like a standard `ForeignKey`... it accepts all the same arguments. If you want to use a `User` model other than the default, just add `USER_MODEL` to your settings file.... it uses dotted notation (`app_label.model_name`). Example: class BlogPost(models.Model): user = UserForeignKey(related_name="blog_posts") title = models.CharField(...) content = models.TextField(...)
Sometimes we want to render items as cells in table with fixed row-count and computable col-count shape and vice versa. It's not difficult to do it with compute odd and even row, col index, but more common way is to use some reshape function. Theare are simple TAG for it: "table", with use reshape function and FILTER "flatindex" wich can use to get flat index in nested loops (may use with table like in this example). Example of usage: `{# List filials must exists in context! #} {% load table %} <table border="0" width="100%"> {% table filials "3x?" %} {% for row in table_obj %} <tr> {% for record in row %} {% if record %} <td class="mf_table_cell" onclick="selcell('filial_{{forloop|flatindex}}')"> <img src="/art/filial.gif" style="margin-bottom: 4px;"/><br/> <span id="filial_{{forloop|flatindex}}" class="mf_table_unselcell">{{ record }}</span> </td> {% else %} <td class="mf_table_cell"> </td> {% endif %} {% endfor %} </tr> {% endfor %} {% endtable %} </table>` /best regards Yosifov Pavel
[A comment on a recent blog entry of mine](http://www.b-list.org/weblog/2008/feb/25/managers/#c63422) asked about a setup where one model has foreign keys pointing at it from several others, and how to write a manager which could attach to any of those models and query seamlessly on the relation regardless of what it's named. This is a simple example of how to do it: in this case, both `Movie` and `Restaurant` have foreign keys to `Review`, albeit under different names. However, they both use `ReviewedObjectManager` to provide a method for querying objects whose review assigned a certain rating; this works because an instance of `ReviewedObjectManager` "knows" what model it's attached to, and can introspect that model, using [Django's model-introspection API](http://www.b-list.org/weblog/2007/nov/04/working-models/), to find out the correct name to use for the relation, and then use that to perform the query. Using model introspection in this fashion is something of an advanced topic, but is extremely useful for writing flexible, reusable code. **Also**, note that the introspection cannot be done in the manager's `__init__()` method -- at that point, `self.model` is still `None` (it won't be filled in with the correct model until a bit later) -- so it's necessary to come up with some way to defer the introspection. In this case, I'm doing it in a method that's called when the relation name is first needed, and which caches the result in an attribute.
Block tag version of [escapejs](http://www.djangoproject.com/documentation/templates/#escapejs). Handy when using inclusion tags to generate AJAX responses.
A simple widget library to provide HTML4 widgets for HTML validation fanatics.
Have you ever felt the need to run multiple Django projects on the same memcached server? How about other cache backends? To scope the cache keys, you simply need to prefix. However, since a lot of Django's internals rely on `django.core.cache.cache`, you cannot easily replace it everywhere. This will automatically upgrade the `django.core.cache.cache` object if `settings.CACHE_PREFIX` is set to a string and the Middleware contains `ScopeCacheMiddleware`. A thread discussing the merging of this functionality into Django is available on [the dev mailing list](http://groups.google.com/group/django-developers/browse_thread/thread/d45edaafec56da2a). However, (as of now) nowhere in the thread does anyone mention the reason why this sort of treatment is needed: Many of Django's internal caching helpers use `django.core.cache.cache`, and will then conflict if multiple sites run on the same cache stores. Example Usage: >>> from django.conf import settings >>> from django.core.cache import cache >>> from scoped_caching import prefix_cache_object >>> settings.CACHE_PREFIX 'FOO_' # Do this once a process (e.g. on import or Middleware) >>> prefix_cache_object(settings.CACHE_PREFIX, cache) >>> cache.set("pi", 3.14159) >>> cache.get("pi") 3.14159 >>> cache.get("pi", use_global_namespace=True) >>> cache.get("FOO_pi", use_global_namespace=True) 3.14159 >>> cache.set("FOO_e", 2.71828, use_global_namespace=True) >>> cache.get("e") 2.71828 To Install: Simply add `ScopeCacheMiddleware` as a middleware and define `settings.CACHE_PREFIX` and enjoy!
This snippet demonstrates the use of the SpecialOps patch ( [link here](http://hackermojo.com/mt-static/archives/2008/02/django-special-ops.html) )to the django 0.96 admin. Once you have the patch, adding actions like these is simple. You can use the @admin_action decorator on model and manager methods to expose them inside the admin. For manager methods, the method should accept a list of IDs. For model methods, only self should be required.