12.30.2010

django-user-registery

I needed to build an auditing system in django and it got me to thinking... What is a graceful way of being to see and get an authenticated user in the context of a model or signal?

I didn't immediately see one so I wrote django-user-registry


I have since deprecated this for function that looks through the stack to find the request signature.
If it finds the request it uses the user from there.

---- Deprecated (Does't work on multithreaded (read all) servers :P ----

The concept is simple create a small middleware class that registers an authenticated user with with a registry class on request and unregisters the user on result.

Then in your model/signal code you can check for and access a user if one exists in the current context.

This code is little naive... it definitely would fall down in a multithreaded environment. Any ideas? The only other way that I can think of implementing it is to walk back up the stack looking for a request...

Example
(in settings.py)

MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',

# 3rd party
# allow access to authenticated users in models and signals
'user_registry.middleware.UserRegistryMiddleware',
)

(in foo/signals.py)

from django.db.models.signals import post_save, post_delete, m2m_changed
from django.dispatch import receiver

from user_registry import UserRegistry

def alert_on_user():
print "alert_on_user"
if UserRegistry.has_user():
user = UserRegistry.get_user()
print user

@receiver(post_save)
def post_save_audit(sender,**kwargs):
alert_on_user()

@receiver(post_delete)
def post_delete_audit(sender,**kwargs):
alert_on_user()

@receiver(m2m_changed)
def m2m_changed_audit(sender,**kwargs):
alert_on_user()

12.28.2010

Update dj_jsurls is now django-jsurls

In order to follow the established plugin naming convention dj_urls is now django-jsurls. Also I got sick of typing dj_jsurls so the js root is now jsurls.

There is templatetags/jsurls - get_jsurls_static_prefix and urls.jsurls_urlpatterns to work around the fact that django.contrib.staticfiles.staticfiles_urlpatterns eats all /static/ paths

Lastly, there is a manage.py generate_static_jsurls to build the static production version of the jsurls.js file.

12.17.2010

DRY out your urls (in JS)

(update: changed url repository)

When it come to xhr heavy JS code, I hate hard coding in urls. This isn't good practice on the Django side and it is not good practice on the JS side. While I was working in ROR for a spell, I found a plugin on github toretore/javascript_routes that built off of ROR routes system. Upon moving back to Django I wanted the same functionality, so I built a pluggable app at sjzabel/django-jsurls.

Right now it is view designed for development use but I'll have management tool to statically generate it for productions here soon.

12.03.2010

Great Gitosis Article

http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way

Django, login required mixin, mixed into all class based generic views

Django, aaaaaaaah...

After a two year stint using Ruby on Rails, I am back in the loving arms of Django.

I've been quite pleased to see that it is growing up but still keeping all the things that I loved about it (the intuitiveness, the flexibility, the ease of hacking, the spectacular documentation, etc...)

So a link Eric Olscher : Large Problems (mostly solved)

In this series of blog posts Eric talks about a number of issues that we had to hand roll solutions to when I was beginning with Django