I am not sure what to say about the state of PyAWS, or its future, what with the multiple forks available and lack of recent updates. The best version I've found is [http://github.com/IanLewis/pyaws](this one), a spiffed-up version of 0.2.2 by Ian Lewis. I wrote this class on top of PyAWS so I could have more pythonic/django-y calling conventions, and to isolate the calls in case I have to swap libraries or versions down the road.
You may want to familiarize yourself with PyAWS before using this. You'll definately need Amazon web service login credentials and keys -- they're available [here](http://aws.amazon.com/) for free.
personally I use it with [these monkeypatching and decorator-decorators](http://www.djangosnippets.org/snippets/1888/) -- at the top of my personal version of the file containing this snippet I use the two (non-silly) examples from that snippet, to make the PyAWS internal Bag collection class work for me.
EXAMPLE USE:
# search Amazon's product database (returns a list of nested dicts)
from amazon import aws
books = aws.search(q='raymond carver')
lenses = aws.search(q='leica summicron', idx='Photo')
# get the data for a specific ASIN/ISBN/EAN/etc ID number
what_we_talk_about_when_we_talk_about_love = aws.fetch(qid='0679723056', idtype='ASIN')
- decorator
- amazon
- amazonapi
- aws
- pyaws
Because the db caching doesn't support atomic operations, it was unsafe to store a list of 'keys' in a single key. So, rather than store the list, I just append each key with a specific tag, and then filter for it later. This means I don't need to worry too much about atomic usage with lists (i.e. queued requests).
However - I still can think of many instances where I would need atomic usage, so I will probably implement this later on down the line. Hopefully, the atomic modifications will be accepted by the core devs.
This also contains threaded cache cleaning, which means you no longer need to rely on requests to clean the cache (which would have potentially slowed the user query down), and will remove any cache entries past their expiry date every 3 minutes.
Enjoy!
Cal
- filter
- cache
- db
- backend
- like
manything need to do with RequestContext, but it's too tedious.
use
`render_to_response("/my.html", {'key':value,},request)`
instead of
`render_to_response("/my.html", {'key':value,},new RequestContext(request)) `
and you can also use
`render_to_response("/my.html", {'key':value,},new RequestContext(request))`
I tried a few snippets of integrated jinja2 in django, which provided ?.render_to_string and ?.render_to_response in the way of jinja2. **But those snippets could not use the generic view**, because of the generic views is use default django template. so i write this snippet which could use generic view, and use the basic django.shortcuts.render_to_string, django.shortcuts.render_to_string.
#in yourproject/urls.py :
#install default environment is very simple
djangojinja2.install()
#install environment of specified Environment class
from jinja2.sandbox import SandboxedEnvironment
djangojinja2.install(SandboxedEnvironment)
#alternative you can install sepcified environment
env=Environment(...)
...
djangojinja2.install(env)
#something could be set in settings.py
TEMPLATE_DIRS = (path.join(path.dirname(__file__),"templates"),)
JINJA_GLOBALS=['myapp.myutil.foo',]
JINJA_FILTERS=['django.template.defaultfilters.date',]
JINJA_TESTS=('foo.mytest',)
JINJA_EXTS=['jinja2.ext.i18n']
#there is no change need for app.views
from django.shortcuts import render_to_response
def foo(request):
return render_to_response('/myjinja2.html',{'request':request})
test in django development version of r12026 , jinja2 2.2.1, python 2.5
- template
- generic
- jinja2
- generic-view