Thoughts on a middleware question John mentioned at the meetup

[Bryan Chow]

I was thinking about the question John posed at the meetup where he
has views that commonly need access to a dictionary of attributes
pulled from the database based on the HTTP user agent. The current
solution is custom middleware that injects the dictionary into the
request object.

Some thoughts:

Assuming that your middleware uses the process_request method, could
you use process_view instead, and perform the lookup conditionally
based on a decorator or parameter passed to the view? This way the
lookup would not have to occur on every request.

Have you considered using the Django Sessions module to store the
result of the query, instead of injecting the dictionary directly into
the request? In theory, this might provide higher performance as
sessions can be cached.

Also, perhaps your middleware, or the library that your middleware
calls, could manually cache results for commonly requested user
agents.

Anyhow, I hope this helps, and that I'm not too uninformed about the
problem. :)

Bryan

[John Boxall]

Hey Bryan,

Just to frame the problem again -

I'm working on a device detection pluggable called "device" using
Device Atlas:
http://deviceatlas.com/

Currently I'm offering two methods to add device related information
to the request object - a decorator and a middleware. Both function
the same way:

1) Get the user agent string from request.META['HTTP_USER_AGENT']
2) Do a lookup for the UA string in Device Atlas.
3) Stash the object returned from Device Atlas into request.

For the middleware I'm using the process_request function:
http://www.djangoproject.com/documentation/middleware/#process-request

I decided to use it instead of process_view because it was my
understanding that it's possible that process_view will never be
called in a request. For instance a 404 intreupts the normal request
cycle. However you might still want access to device information to
display in your 404 page.

Bryan you bring up some very good points -

Certainly I should add caching of some sort - but I'm not sure whether
it should be user specific as with sessions. Users may access the same
site with different devices. Perhaps as you suggested, it would be
better to cache the results of the Device Atlas query so that if the
same UA string showed up it could be pulled from the cache.

Cheers,

John

[Bryan Chow]

I was being intentionally vague with details as I was unsure how much
information about your project was appropriate for discussion on a
public forum. :)

Sounds like you've considered your caching options already. And after
looking further into Device Atlas, it seems that Device Atlas itself
may also have its own caching mechanisms?

Have you considered the pros and cons of setting the Device Atlas
results in the context, instead of injecting it directly into the
request object?

Bryan

[John Boxall]

The implementation details aren't much of a secret :)

http://code.google.com/p/django-bloom/source/browse/#svn/trunk/bloom/device

Bryan - by setting the results in the context do you mean using a
TEMPLATE_CONTEXT_PROCESSORS?

http://www.b-list.org/weblog/2006/jun/14/django-tips-template-context-processors/

Certainly it's another interesting way to access the functionality
that may would require less code than writing '@detect_device'
everywhere. I'll try coding it up!

John

[Bryan Chow]

I didn't know that the code had been released. Nice!

If using a context processor works out for you, here are some ideas
from Matt Erkkila on improving performance using the Django cache
framework and lazy loading:

http://matterkkila.com/2008/03/23/context-processors-caching-and-lazy-loading-oh-my/

Cheers,
Bryan

On Aug 1, 8:26 am, John Boxall <bisha...@gmail.com> wrote:
> The implementation details aren't much of a secret :)
>

> http://code.google.com/p/django-bloom/source/browse/#svn/trunk/bloom/...

>
> Bryan - by setting the results in the context do you mean using a
> TEMPLATE_CONTEXT_PROCESSORS?
>

> http://www.b-list.org/weblog/2006/jun/14/django-tips-template-context...