Re: Dynamic settings variables (dynamic global variable)
A method similar to what Anssi describes is what we use for local
caching of data that is too large to comfortably fetch from cache/
parse from file every time we need it. A Doing a lazy fetch with a
maximum age like that also helps with load times since it is only
fetched when accessed. Of course the fetch needs to be reasonably
possible with the time frame of a single request in order to not
frustrate users.
# Put this class somewhere and import into your settings.py
import datetime
import urllib2
class LazyFetch(object):
def __init__(self,url,max_age=60*60):
self.url=url
self.reload_delta=datetime.timedelta(seconds=max_age)
def _get_content(self):
last_updated=getattr(self,'_last_updated',None)
if not last_updated or datetime.datetime.now()-last_updated >
self.reload_delta:
self._content=urllib2.urlopen(self.url).read()
self._age=datetime.datetime.now()
return self._content
content=property(_get_content)
somepage=LazyFetch("http://www.example.com",30)
then elsewhere in your code you can import settings and access the
page content
current_content=settings.somepage.content
Accessing the property "content" would call get_content() which checks
to see if the content hasn't been loaded, or expired.. and reloads on
demand. This is just a barebones example though, you'd want to throw
in some exception handing to the urlopen call at the very least.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Dynamic settings variables (dynamic global variable)
I made an error when I changed a variable name just before posting. Replace "self._age" with "self._last_updated". -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Dynamic settings variables (dynamic global variable)
> Doug, I don't see how the LazyFetch you wrote is much different than > what akaariai shared? Can you explain to me what the difference is? > And I'm not saying that in a condescending way, I'm saying I'm just > not sharp enough on my Python to recognize the difference. Slightly different implementation of the same idea. From your reply to his post I thought there was still some confusion on the concept so I did a modification of a class we use in a project so that you could have a tested/working sample. They are fundamentally the same approach to the problem, it just seemed to me that treating an instance of the class as the 'page' variable rather than 'cache' used to fetch a url might be clearer as an example. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Much the same code, different businesses
There are a few choices that I'm familiar with. 1) Create a separate project/settings file for each of your stores, overriding templates as needed by placing assigning a template path for the project. I think this is pretty much the recommended way to do things, especially if the number of sites are reasonably small. It offers great data isolation (using a different database for each), and it allows you to use all kinds of django apps and plugins. For mass hosting, this is going to require more resources since you'll have workers for each site rather than a shared pool of workers. 2) Do some 'strange things', such as changing database or schema on a per-request basis using threadlocals and a middleware. This offers much of the capability of 1, but there may be compatibility issues (module level caching for example) and tricky foreignkey restrictions.http://tidbids.posterous.com/saas-with-django-and-postgresql That post, and some of the comments will probably be of interest to you. 2) Do your own multi-tenant user setup. There isn't anything built in for this, and as a result you lose a lot of the built in functionality like the admin as well as any hope of using user aware third-party apps. This is the way I ended up going. We use a custom template loader/middleware to check for site specific templates, site specific caching, and a custom siteuser/site framework. All data is stored in the same database, with ownership linked back to the custom siteusers/ sites and permission checking related to the views. We keep the django user and sites framework as well, but use it/the admin for administration use only. This is the most complicated path, but I think the advantages make it worth it for a large number of sites. We can add sites using an admin interface, and use fewer resources since caching and workers are all shared. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: PythonScript(Zope) like in a django app, any tips?
You might also try a different scripting language, for example Lua. I've a python module "lupa" bookmarked for a project on my todo list that requires user scripting. It appears you can have a relatively sandboxed access to python objects. I'm hoping that with some careful compiling of the luajit compiler it will use a limited set of libraries, providing only simple/non-dangerous capability. I haven't tried any of this yet though, so just food for thought. http://pypi.python.org/pypi/lupa -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Scaling django installation
I don't think anyone will be able to give you a good evaluation without knowing more about the requests. Django itself could probably handle 10k requests per second returning a simple "hello world" response, or less than 10 if you are returning very large/difficult to generate responses. It is what your app does that is going to make all the difference. The djangobook.com site has some good info on scaling, despite being for a much older version of django. Ignore the code, and skip down the the section on scaling: http://www.djangobook.com/en/1.0/chapter20/ >From my own experience, caching/memcache can make all the difference in the world. Find out what is taking the time, and cache it. Different approaches to your page design can help too. If the page is 95% identical for all users, cache the 95% and pull in the 5% with javascript to personalize. Allowing something like varnish to sit in front of those expensive to generate, but cachable pages is another way to speed things up but it requires a bit of application specific configuration to be useful (ignoring cookies for certain urls, making sure you are setting the vary header correctly in your app, etc). -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Understanding Django for PHP developer
http://www.twistedcommons.com/2008/12/how-django-works.html
There was a blog post several years ago that followed, in detail, the
life of a response with all the gory details. Unfortunately I can't
locate the link. The above page is brief, but has a nice picture that
is easy to follow.
A huge difference is that php code has access to just about every
thing in the global space of the script. It has access to headers,
cookies, path information, querystrings, and pretty much all the
information it might need. Django bundles that into a request object
and requires that you explicitly pass data about the request to your
code, In php you could access $_GET in an arbitrary function and it
would just work. The request.GET equivalent in Django is only
available if you pass it into the function.
Since code may be reused for the next request, it's possible for
changes to have polluted values from the first request if you
accidentally do something your shouldn't. This requires a little more
caution when writing your code, but is not difficult.
For example consider a function like:
def myfunc(listofstuff=[]):
listofstuff.append('I was called')
return listofstuff
If you call the function in the first request without a parameter
"myfunc()" it will default to an empty list, append "I was called" and
return a list with a single item ["I was called"], and everything will
work fine. The gotcha is that the empty list was defined when the
function was created, so the second request will get the -same- list,
which this time will not be empty, and the second call will return ["I
was called","I was called"].
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Understanding Django for PHP developer
I should have looked a little harder, I found the blog post. It is about a much older version of Django. Some of the references to django internals are surely a bit different now, but the fundamentals are the same. It really helped me when I first started. I'd love to see it updated for the current versions and part of the official docs. http://www.b-list.org/weblog/2006/jun/13/how-django-processes-request/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Variable # of fields in a form
It seems to me that two fields might be the simple solution?
class SomeForm(Form):
internal = forms.ModelMultipleChoiceField(
,
widget=forms.CheckboxSelectMultiple)
externa = forms.ModelMultipleChoiceField(
,
widget=forms.CheckboxSelectMultiple)
Then you can just output them in your layout {{form.internal}} and
{{form.external}}
Another thing that might be of interest to you is crispy forms:
https://github.com/maraujop/django-crispy-forms/
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: django doesnt accept the serializeArray POST data
I'm guessing it is a result of not having a csrf token set for the post: https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Work in memory instead of BD, how to?
You probably don't want to cache changes. Or if you do, it would be better done elsewhere (like a caching raid controller/w battery on your database machine). The usual cache patterns I've seen are: 1) Fetch from database 2) Store in cache with a reasonable timeout to that changes are reflected as the cache expires 3) Look in cache, if found return that. If not goto step (1) or 1) Fetch from database 2) Store in cache with a -long- timeout 2.5) Track changes to cached objects and update the stored information if it changes. 3) Look in cache, if found return it. if not goto step(1) since the changes won't be reflected as rapidly due to the long timeout, you can configure the post_save/post_delete/etc signals to automatically update the cached value every time a change is made to one of that models instances. This is what the django-cache-utils app is doing for you. The trick is that the more complicated your use, the more complex the cache invalidation is going to have to be. Another possiblity is that caching may be the wrong solution to your problem. If for example a web request need to do so a bunch of expensive operations, but does not need to do them interactively with your user, a solution like django-celery may be better. With celery the job gets scheduled for execution outside of the web request- response system (possibly even on another machine) and gives you a job id. This allows the user to get on with things, leaving the work to be done behind the scenes. If the user needs to know the results or state of the job you can use ajax or refreshing to check back using the id to retreive the results when the job completes. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: find_template Django 1.3
I haven't moved to 1.3 yet, but we do a few things with the template source too so this is definitely of interest. It looks like most of the template loaders define a load_template_source method implementation that does return the source, except for the cached loader. As a work around you could add a module with your own find_template_source() method based on the existing, but calling the load_template_source() method instead: from django.template.loader import template_source_loaders,find_template_loader,make_origin,TemplateDoesNotExist from django.conf import settings def find_template_source(name, dirs=None): global template_source_loaders if template_source_loaders is None: loaders = [] for loader_name in settings.TEMPLATE_LOADERS: loader = find_template_loader(loader_name) if loader is not None: loaders.append(loader) template_source_loaders = tuple(loaders) for loader in template_source_loaders: try: source, display_name = loader.load_template_source(name, dirs) return (source, make_origin(display_name, loader, name, dirs)) except TemplateDoesNotExist: pass except NotImplementedError: pass raise TemplateDoesNotExist(name) If you want to use the cache loader too, you'd have to subclass it and define your own load_template_source() implementation. I hope this functionality gets added back to the core. There isn't any reason not to that I can see. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Argh: templates, admin, and app loading order
Can you use the filesystem loader as the first template loader, then set TEMPLATE_DIRS in settings.py to specify a template directory outside any app? Use this location for all of your overrides, just make sure the path is right... ie each app you override would have its own subdirectory. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Security implications of using the form.fields dictionary directly
The most elegant way I've seen specialized form rendering handled was
the use of template tags and filters. The django uni-form project is
a good example. By using the filter and template tags you gain full
access to all the form elements, and can do easy manipulation in
python, but leave the rendering and html to a template.
if you wanted your multiplecheckboxes field to render in three columns
you could write a filter (formfield_columns for example) that took the
formfield as parameter, and the number of columns and returned the
appropriate breakdown with the right info that might be used something
like this:
{% for row in myform.field|formfield_columns:3 %}
{% for cb in row %}
{{cb.label}}
{% endfor %}
{% endfor %}
where your filter converted the field into a list of rows, with each
checkbox representating a dict populated with values (keys checked,
name, id, label) from the form field.
you could also make a filter that does a single value in your
multiplecheckbox field
{{form.field|formcheckbox_value:"myvalue"}}
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Streamlining DJango Deployment — Novel idea from the world of CMSs
I would agree with Donald, and expand on that to say that an installer would probably be best written in php for widest compatibility. A php based installer would run outof the box on most webservers, and be able to give a guided overview of the python/web environment setup. It would easily be able to detect the apache/webserver configuration for required modules, make 'best practices' recommendations based on the environment, download and setup virtualenv, etc. Not a php fan, but it would seem to me to be a prime choice for an installer to let django/python webdevelopment ease into a php dominated world. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: When is a good time to use db_index? Rule of thumb?
Another clarification: It tells django to create an index on that field when you run syncdb to create the tables for your apps. Adding it to an existing model won't change anything by itself. If you decide a field needs an index you can add it to the model definition, and then you can use the "manage.py sqlindexes" command to see what the sql commands are to create the indexes. You'll need to run the create index sql for that field manually using psql (assuming postgres) or some other database client to add the indexes outside of django. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: How to make a query form depend on a field?
There are also a few third-party apps that can assist you with the form->query process such as this one: https://github.com/alex/django-filter -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: custom attributes of model field
I may not be clear on what you are trying to accomplish, but maybe
something like
class Form1(forms.ModelForm):
class Meta:
model=Model
def type_one_fields(self):
return [self.fields['a']] # Or use whatever criteria you want
for type_one fields.
def type_two_fields(self):
return [self.fields['b']]
def type_three_fields(self):
return [self.fields['c']]
{% for field in form.type_one_fields %}{{field}}{% endfor %}
I don't think the model is where you'd want to do any form/display
stuff. It would be best kept on the form, or as a template tag. If
you are trying to make a 'generic' configuration such as putting all
text fields in one section, fks in another, etc... you could make a
filter:
{% for field in form|field_type:"text" %}{{field}}{% endif %}
{% for field in form|field_type:"foreignkey" %}{{field}}{% endif %}
The filter would have to be smart enough to inspect the form variable
and pick the right fields either by widget, checking a mapping on the
model, or some other criteria that fits exactly what you are trying to
do.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: custom attributes of model field
Just to clarify that last bit about a mapping on the model since it's
closest to what you originally described. Just pseudo-code, but you
can see the idea.
class Model1(models.Model):
FIELD_DISPLAY={
'foo': ['a'],
'bar': ['b','c']
}
a = models.CharField()
b = models.ForeignKey('Model2')
c = models.IntegerField()
{% for field in form|field_type:"foo" %}{{field}}{% endfor %}
{% for field in form|field_type:"bar" %}{{field}}{% endfor %}
@register.filter
def form_field(form,key):
fields=form.Meta.model.FIELD_DISPLAY[key]
return [form.fields[fn] for f in fields]
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: rendering CSV in response; need a little help
If you have a dataset that is too large to fit in memory comfortably,
the ability to pass a generator to an httpresponse means you can break
it up into multiple smaller queries (outside the template system
anyway):
def queryset_to_csv(queryset,delimiter=',',steps=500):
""" generator for large querysets """
try: # raw query set
fieldmeta = queryset.model._meta.fields
except AttributeError: # it's been evaluated
fieldmeta = qs._meta.fields
fields = []
row= []
for f in fieldmeta:
fields.append(f.get_attname())
row.append('"'+f.name+'"')
yield "%s\r\n" % delimiter.join(row)
ids=[o["id"] for o in queryset.values("id")]
count=len(ids)
for n in range(steps,count+steps,steps):
lo,hi=n-steps,n
qs=queryset.model.objects.filter(pk__in=ids[lo:hi])
it=[]
for i in qs:
row = []
for f in fields:
val =
str(getattr(i,f)).replace('"',"'").replace(delimiter,' ')
row.append('"'+val+'"')
it.append(delimiter.join(row))
yield "\r\n".join(it)
...
return HttpResponse(queryset_to_csv(somequeryset,',',
250),mimetype='text/csv')
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: django search query
On Saturday, June 29, 2013 11:32:19 PM UTC-5, Harjot Mann wrote: > > Is there any search query in django which can ignore vowels like I want to > make a query which displays all the clients name who writes their name as > 'amanjit' or 'amanjeet'. > It should take take ee=i or anything like this. Please help me I have to > finish my task asap. > http://www.postgresql.org/docs/9.1/static/fuzzystrmatch.html You should be able to do it with the django .extra() method easy enough. I believe you can also make a soundex index on columns to improve the performance. The python jellyfish library is nice for pre-calculating phonetic strings and storing them in the database to compare against, or for small data sets that you want to process in python. A third option is something like https://github.com/niwibe/djorm-ext-pgfulltext which uses postgres full text search. The full text search uses tokens that are normalized. I'm not sure it it would normalize amanjit to amanjeet with the default configuration, and may be overkill for what you want. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: Big Picture?
A suggestion: Make the return arrow from views more clearly indicate that return path goes through the middleware (since it passes through once as a request, and back through the middleware in reverse with the response) and back through the webserver layers. I'm probably asking for a lot, but it sure would be nice to show the 'standard' middlewares with simple descriptions (sessions, authentication, csrf for example). Quite a bit of 'magic' happens in middleware. Love the idea of the diagram though, would have been a huge help when I first started using Django. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: Is Celery the best option?
Celery is a good option, and probably the most used. There are a couple of other options that may be worth looking into: Huey https://github.com/coleifer/huey Rq http://python-rq.org/ Personally I've never gotten on well with celery. It's just not at all intuitive to me (it's heavy use of decorators). Rq was a better fit. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: Hosting multiple sites on a single application
I can't recommend either of those solutions specifically, but I have been using an approach similar to that of django-multisite running on a threaded fastcgi instance since django .96 days and it has worked well for us. My main concern would be with third-party apps that set static data initially from settings, and would bypass any per-request changes. A seconday concern is with caching and handling cached templates, which means writing your own per-site template loader or not using template caching. You can host multiple domains from one instance with a bit of work and auditing all the 3rd pary code you use to make sure it does what you expect, but it does add some quirks. Worth it for the memory savings in my opinion though if you are willing to be careful and you are doing very little other than template customization for each site. It also makes maintenance and upgrades much simpler. On Tuesday, September 17, 2013 4:12:32 AM UTC-5, James Zildjian wrote: > > > Hi > > I am trying to run around 50 mini sites which share about 90% of their > code. Each site simply queries and API and returns the results, and will be > on it's own domain, and have a different style.css and config.py. The > userbase (and the database generally) will be shared across the board. My > initial idea was to run them as separate applications with a common > library, each with their own UWSGI thread. However, I have concerns about > large memory use. > > I have read about the sites framework which would allow them to run from a > single instance. > 4 > > https://docs.djangoproject.com/en/dev/ref/contrib/sites/ > > My question is, is the site framework the right approach to a problem like > this, and does it have real benefits over running separate applications. I > have heard the following: > > *Your SITE_ID is set in settings.py, so in order to have multiple sites, > you need multiple settings.py configurations, which means multiple distinct > processes/instances. You can of course share the code base between them, > but each site will need a dedicated worker / WSGIDaemon to serve the site. > * > > Alternative ideas of systems: > > https://github.com/iivvoo/django_layers > https://github.com/shestera/django-multisite > > Any ideas or help would be most appreciated. > > James > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: Is there an HTML editor that's Django-aware
Everyone has different requirements, but I'm one of those strange people who don't care about having a powerful editor. I don't want completion, or auto-anything. Just something that gets out of my way and lets me work. If something complex needs to be done on occasion, that's what the shell and associated command tools are good for. I also prefer an editor that doesn't suck up a gig of ram like most of the java based editors/IDEs seem to. My search for a simple editor with basic project support ended up with a relatively new gtksourceview2 based editor called Codeslayer: Starts in around a second, and uses a whopping 20m of ram: http://code.google.com/p/codeslayer/ with a django language-spec: http://code.google.com/p/gedit-django-template-language/ and a decent theme, and additional language-spec for python: http://mystilleef.blogspot.com/2010/07/new-dark-minimalist-theme-for.html Which ends up looking like this: http://tinyurl.com/43v8dcf Gedit with plugins is similar, but a bit heavier - I also had a lot of trouble with the filebrowser/project manager working over sshfs at reasonable speed. Another lightweight alternative is PIDA with emacs or VIM as the editor base. If you can handle the learning curve, which I don't care to: http://pida.co.uk/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Our new startup site build on Django and GAE is now live!
I actually authorized, but got a little creeped out by being asked for three cities in which I'd lived before being able to continue. I entered one, but it still wouldn't let me pass without another two. I couldn't conceived of ANY legitimate reason to need anything more than my current location aside from data mining, so I cancelled/logged out and removed authorization from facebook. Behind the blur it looked interesting, but you'll have to convince me you need all that info before I'd ever register. I haven't even -lived- in three different cities. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: How to implement multi-tenant, single DB, single site?
For our setup we created a separate user,site framework since we do a form of vhosting that serves multiple sites from one instance. We have a Site model that serves as the root tying all of our other models together. No abstract models or anything fancy, just a FK in each model class pointing back to the Site model. You only have one site, but the concept could be the same.. instead of setting the site instance for a request in middleware from ip/header info like we do, you'd infer and organization instance from the logged on user. For the view management I'd suggest looking at the class based views, and creating a 'tenant aware' base class view that you can sublcass for your individual views. I used the generic class based views as a guide for making my own. I'd suggest starting by looking at the source in django.views.generic.list and django.views.generic.detail. The get_queryset()/get_object methods are the main points of interest. If you have a middlware set the user (or use django's user model) object on the request, you can alter your get_queryset() method to restrict the query to only objects the user (or that users organization) is allowed since the request will be available on the class as self.request. For my use, I have a similar base class with an altered dispatch() method that wraps the base dispatch method in a try/except looking for an AuthError exception. In my view subclasses I override get_queryset() to limit queryset per request (to the site/user), and do additional permissions checking in get_context_data() raising an AuthError exception if there is a permission error. The altered dispatch is responsible for returning an error page or redirecting to a login if AuthError is raised at any point in the view process. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Implementing a User Search Feature
If you just want a simple user search (which seems to be what you are
asking for), it really depends on your models - but a basic approach I
usually use is to define a django form to use for the search, and
instead of defining a save method, make a method that returns a
queryset. As an off the top of my head example for a django auth user
(untested, I might have screwed something up):
class UserSearchForm(forms.Form):
first_name__istartswith=forms.CharField(label="First name",
required=False)
last_name__istartswith=forms.CharField(label="Last name",
required=False)
def queryset(self):
from django.contrib.auth.models import User
filters={}
for k,v in self.cleaned_data.items():
val=v.strip()
if val: filters[k]=val
return User.objects.filter(**filters)
Then use it in your view like any other form:
def user_search(request):
usf=UserSearchForm(request.GET or
request.POST,prefix='usersearch')
users=usf.queryset()
return render_to_response('sometemplate.html',{'users':users})
Now if you really do want to do text indexing and have full text
search capabilities then you should look at the other suggestions.
For many things those are either overkill or too generic.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Implementing a User Search Feature
**filters is python for expand the dict 'filters' into keyword
arguments.
ie
filters={'foo':1}
model.objects.filter(**filters)
is the same as
model.objects.filter(foo=1)
The filters variable is just temporary dictionary for building the
keyword arguments from the form data, electing to omit any empty
values (no point for a search), and then expanding that temp
dictionary into the keyword search arguments needed for the filter()
method. The names on the form correspond to the lookup names you'd
use for the query.
If you use that form to search for first name 'raj', the filters
dictionary should end up looking like:
{'first_name__istartswith':'raj'}
which would expand (**) to the equivalent of
User.objects.filter(first_name__istartswith='raj')
On Jul 2, 11:53 am, raj wrote:
> Just a quick question, the **filters thing u placed, i would put
> something like first_name last_name or something right?
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Doesn't render templates any longer
def main(request):
context=Context()
this_is_the_template_object = loader.get_template("main/
start.html")
this_is_the_template_rendered=this_is_the_template_object.render(context)
return HttpResponse(this_is_the_template_rendered)
What you are feeding HttpResponse is the object rather than the
rendered template.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Most stable Linux distribution for Django - Python development
I'll second the use of something like LXC (new to me) or OpenVZ (what we use), allowing you to run/test multiple distros at once. If you want to try debian (or pretty much any linux distro), download a container skeleton for it and install in a few seconds. I've used virtualbox/kvm, but I found containers in openvz to be much easier to work with. A 'machine' is simply a folder on the host server. You can zip it up, move between machines, rsync it. Whatever. It's like virtualenv for distros. To be able to rsync/clone an entire container to create a second instance for upgrade or other testing is a wonderful thing. Since we also use in production, it's a simple remote rsync to have a fully working clone of our live servers for troubleshooting too. I can't imagine going back at this point, and even run it on single purpose machines in production for the flexibilty. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django for a front end designer
I don't think it's necessarily a choice between learning php or learning python. Most programming languages are fairly similar in concept, and once you've mastered one it's reasonably easy to pick up a new one. Python is a great language, but I think it's especially great as a first language. Your time spent learning python and django will not be wasted if you also choose to learn/use php. I think it's much easier to learn good methodology and practices with python, and then carry those practices over to php than than the other way around. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: How do I apply a filter in a custom template tag?
I'd like to see you model structure, but based on what I think it is:
class Entry(model.Model):
categories=models.ManyToManyField(Category)
class Content(models.Model):
entry=models.ForeignKey(Entry)
You have a Content Instance
You want to see other entries belonging to one or more of the
categories for that Content instances Entry instance
You could do a custom template tag like yours:
{% get_related_entries content_instance.entry as related_entries %}
That tag would do something like the following :
#fetching primary key only since we don't need the whole thing
category_ids=content_instance.entry.categories.values("pk")
context['related_entries']=Entry.objects.filter(pk__in=category_ids)
That would work, but my choice would probably be to add a method to
your Entry class.
class Entry(models.Model):
categories=models.ManyToManyField(Category)
def related_entries(self,**filters):
return
Entry.objects.filter(pk__in=self.categories.filter(**filters).values("pk"))
That way you don't need a tag at all. Just do:
{% for related_entry in content.entry.related_entries %}
...
{% endfor %}
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: How to store variable timedeltas in a Django model?
Depending on the resolution and maximum duration, you could just use an integerfield containing either the number of seconds or minutes, and then recreate it. That way you can also base queries off of the value, which you can't do with just a pickle field. Of you could subclass the integerfield and make it accept/return timdelta objects similar to how the pickled version is above. The max duration depends on the data type in your database backend. Postgres I think is +/- -214748364 or so. If you use a resolution of seconds, that is a limit of about 68 years. Using minute resolution would be about 4 millenia. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Confused about thread locals... again.
First, I'd like to find out if there is a better way than thread locals to do what I want to do. From what I can tell, it isn't possible any other way. Finally, I don't understand why my thread locals implementation/hack works - which scares me, so I would like to ask the wiser gurus out there for an explanation. Need: To alter the template path used by a custom template loader based on the the request object. Specifically I want to alter it based on the incoming domain, and sanitized cookie value allowing 'theme' selection. I have a basic theme setup using thread locals that works. in the same module/directory I have: base.py -> contains the theme objects, thread locals variable, and a couple of get/set functions that just use getattr/setattr to set a theme attribute on the local() instance. middleware.py -> contains the middleware that calls my "set theme" function loader.py-> contains the template loader which calls my "get theme" function The base setup works fine, but was written with the intention of subclassing it for another app to set the theme according to a 'site' object that gets created by another middleware (we serve multiple sites from one fastcgi instance). So I have another middleware.py file in another app that imports my ThemeMiddleware and subclasses it overriding the method returns the template path to cause the loader to look for that sites templates. This does not work. I get two different thread locals instances (print shows different addresses), despite all manipulation of the local variable happening in base.py just as it did in the working version. I've had issues in the past with thread locals working differently depending on module import method. So I stripped out the thread locals bit from base.py and put in all by itself in thread_locals.py: --- try: from threading import local except ImportError: from django.utils._threading_local import local thread_local=local() Now in base.py I added 'from thread_locals import thread_local' at the top of the module, and nothing else changes. I was hoping that the same import statment (it's only imported once, in one file) would bypass the problem, but it doesn't. Next I moved the thread_locals.py file from the same directory as my other theme files to the project root, in the same location as django's settings.py. No other changes were made. It works. I should be happy, but I'm not comfortable allowing solutions I don't reasonably understand to go into production. I'd love to drop thread locals entirely, but short of that some understanding of what is happening and why would be a big help. I googled the heck out if it, but didn't find anything that fit. Thanks! -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Confused about thread locals... again.
@ringemip Thanks for the reply. I've been considering something like that, but given the number of views and tags involved, it would be a very long process. Especially since I used a new context instance in most of my custom tags that render another template, rather the pushing, rendering, poping the original like I should have. As much as I don't want to use thread_locals, it seems like the best (interim) approach. The long term plan will definitely move to something like you describe. It will also give a nice consistent use pattern when a request object isn't available (ie async mail templates). I'd still love to know why the import/locals object is so touchy. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django's documention is horrible
The reason I chose django in the first place was the documentation. Compared to everything out there, it was incredible. Back then it also had a helpful comments section on each page where people chimed in to clarify various parts of the document. It reads like a text book, which is a big help when learning the framework. Unfortunately it reads like a text book, which is a big pain when you know the story and just need the details. The wonderful code snippets lose their context. The lengthy explanations and sequential introduction of facts becomes more hinderence than help when trying to find that one bit you know is in there somewhere, but it's a needle in a haystack. It's designed for reading, not so much for reference. It's also definitely not for the impatient. After several years with Django, I usually find it easier to just poke around the source. It's all layed out logically and, and if you have a general overview of the framework it's much faster than trying to scan through the online docs. Unfortunately this approach requires a certain level of familiarity with how django works to get the most out of it. A few things I think would help make a big difference (they would have to me at least): 1) A couple of complete reference examples. Not just snippets introduced a few lines at a time, but full working examples you can unzip and expect to work and provide a simple reference to the basics. I've been using django for 3 years now in developing a fairly complex project. I'm still not 100% clear on the best way to layout a project. What I have obviously works, and I'm stuck with it now... but it was a guess back when I first started.I realize there is no one size fits all answer for that type of question, but a tiny working example with one project and two apps would go along way to providing someone first starting out, especially if the projects did simple introductions to all the major topics: a view, a view with an authentication decorator, a good example of template inheritance use to 'theme' a site, a few of forms, severa of which don't use a helper (ie no ModelForm) and requires some inter-field validation, maybe a simple middlware that reads/writes a cookie. A custom tag/filter or two. Something that showcases the "admin is not your app" principle. I really would love to do this, but I'm a little concerned it would turn out to be a bad example here and there! If there is interest I'd volunteer to give it a go though. 2) An overview of how django processes a request. From start to finish, concise on one page with links to the appropriate details if necessary. Possibly a paragraph or two explaining how it differs from say php. In my opinion this should be the first page of the documentation, well before the tutorial. The following page is ancient, but a good example of what I mean. It wasn't until I read it that everything just kinda clicked. Too bad it took a good 6 months for me to run across it more or less on accident. http://www.b-list.org/weblog/2006/jun/13/how-django-processes-request/ 3) The page comments for the existing documentation. I really miss that feature. The comment system PHP uses improves their documentation many times over. With Django's great community I'm sure we'd get a lot of good additions, though moderating the comments makes more work for someone. 4) A small 'best practices' reference not about the django details, but the big picture. Using virtualev. Project layout. Admin vs app. Considerations to keep in mind for writing reusable apps. Production vs Development configurations and switching. Handling timezone conversions. Avoiding performance pitfalls when using orm queries. Signals, how they can be useful. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: django-ttag -- an easier way to write template tags
Thank you! I've been wishing something like this was a part of Django since trying to write my first tag. I've been using something in house that provides similar functionality for a couple of years and couldn't live without it. Your implementation is much more complete (validation) and I'm looking forward to giving it a try. It would be really great if something like this made it's way into contrib or core. Being able to -easily- give your template designers a little extra control while still maintaing clean separation makes everyone happier. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: compiled regex as attribute
Have you done any performance testing? From what I understand pythons re.compile caches internally, so after the first call subsequent calls will use the pre-compiled expression. Serializing the compiled expression using pickle isn't 'free', so I'm wondering how much difference there is in practice. Maybe a compromise of a normal model text field storing the regular expression string you build when the model is saved, and then a propery to simulate a read-only/don-demand the compiled version when you need it. ie something like: class Product(models.Model): # ... canonical_name = models.CharField(max_length=200) spelling_variants = models.CharField(max_length=1, blank=True) lexical_variants = models.CharField(max_length=1, blank=True) excluded = models.CharField(max_length=1, blank=True) permutations = models.CharField(max_length=1000, blank=True) re_str=models.TextField() compiled_re=property(lambda p: re.compile(p.re_str)) def save(self,*args,**kwargs): # do your regular expression string build here and store in self.re_str Although it seems to me like each variant propably belongs as a separate model, linking to your product. That way you can search on it, and add/remove variants fairly easily. To match now, you'd have to pull a bunch of products in a query and test each one. The database server isn't going to sweat a few hundred or even thousand names. class Variant(models.Model): name=models.CharField(db_index=True) product=models.ForeignKey(Product) Product.objects.filter(variant__name='oha android 1.1') -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: How to reduce DB queries?
Could you do a ManyToMany relationship through an intermediary model, and then query the intermediary using select related? -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Need Direction for Web App
I was waiting on Christmas dinner, and had an hour to kill so I threw together a quick, incomplete skeleton app. Maybe it can be of use to get you started on the django side. It relies on the django-macaddress package, but is otherwise standalone. It's very basic - the less there is of it, the easier to follow for someone new to django/python. To make it functional you'd need to edit the alter_dhcp_conf() method to do the heavy lifting of securely updating your dhcpd conf and making the daemon reload. That method will run any time a device is added or removed. https://github.com/dballanc/dhcp-example-skel Good luck, and welcome to the community. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/c7dbc5e5-22e2-4079-96f6-69ae98deceae%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Honest feedback
There have been small, well thought out changes over the last 4 years but fundamentally most still remains pretty much the same. I have several installs running an patched old .96 version, as well as newer stuff with later versions. It all feels about the same to work with. I recently upgraded one from 1.3 to the current with no breakage at all. They've remained pretty true to the promise of backwards compatibility. That also means some of the warts are still there like the difficulty in writing reusable apps, file based settings, multiple user profiles, that 30 char username length on the contrib.auth.User model. Todays Django is a more mature, stable version of what you probably remember. There have been some changes like south becoming the defacto standard for migrations, and geojango now a bundled part of django. I think the biggest thing overall is the number of 3rd party apps available ( https://www.djangopackages.com/ ). There are some really useful ones like tastypie and django rest framework for out of box API (like the admin was for orm). Celery for async tasks, several very nice CMS, Authentication backends for most of the social media sites via python-social-auth. Several nice asset managers. Some nice things in the ORM too, like inheritance and a more useful select_related implementation. Oh, and multiple database support! Templates can now be cached. The storages api was introduced and there are several backends for doing things like uploading to amazon or other similar apis. Sorry for the rambling, just throwing stuff out there! -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/7ab155f4-a39f-4b45-af20-b03f7b6ad025%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Do I need an API?
I'm not clear on your question. I can't tell if you are wanting to allow them to edit the site layout (templates) or content that happens to contain html? Either way, you might look into using the Ace javascript based code editor http://ace.c9.io/ If you are talking about letting them modify the templates, what we do is have a directory for each templates that is at the top of the template loader order, so all templates can be overridden. A kind of 'theme' folder that contains the files we want to allow admins to edit. It's fairly easy to walk that directory structure and give them a list of editable files, and then pull up a page with Ace to edit them. Things get a lot more complicated if you want to allow admins to override arbitrary app level templates, but it's possible too with some modified template loaders so you can track the source with regard to template resolution order. Changes still get saved to the override directory, so no changes are made to the module level templates and they can just delete the custom file to return to original. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/3bdbe0a6-d68a-4c4e-ae41-1235626f0ad0%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
DB Router not working on production machine, works on dev.
I've got a weird one I just can't figure out. I'd love some help while I'm
still sane.
On my development machine all is well. On the other machine the database
router seems to be getting the parent class (which is an abstract model in
another app). I determined this with some print statements on the
router(s):
def db_for_read(self,model,**hints):
print model
print "router checked geo %s" % model._meta.app_label
if model._meta.app_label in self.GEOAPPS:
print "routed geo"
return 'geo'
return None
machine 1 (working):
In [1]: from glvar import models as gm
In [2]: gm.Listing.objects.count()
router checked geo glvar
router checked glvar glvar
routed glvar
Out[2]: 17373
Machine 2 (not working):
In [1]: from glvar import models as gm
In [2]: gm.Listing.objects.count()
router checked geo feedbase
router checked glvar feedbase
Out[2]: 0
The database is there and fine if I specify via using on machine2:
In [3]: gm.Listing.objects.using('glvar').count()
Out[3]: 25171
feedbase.models.Listing is the abstract base for glvar.models.Listing
The code is identical on both machines except for the settings.py file,
confirmed by diff -qr on their respective directories. I deleted all pyc
files to make sure nothing funny was going on there. The only differences
there are in the name of the postgres user, and the library path for
geos/gdal. I updated both django versions to 1.6.5, so those are the same
as well. I'm not sure where I should begin tracking this down -
suggestions?
(venv)[uidx@dev v3]$ diff app/app/settings.py prod/app/settings.py
49,50c49,50
< GEOS_LIBRARY_PATH = '/usr/lib/libgeos_c.so'
< GDAL_LIBRARY_PATH = '/usr/lib/libgdal.so'
---
> GEOS_LIBRARY_PATH = '/usr/lib64/libgeos_c.so'
> GDAL_LIBRARY_PATH = '/usr/lib64/libgdal.so'
142,143c142,143
< 'NAME': 'glvar',
< 'USER': 'uidx',
---
> 'NAME': 'glvar',
> 'USER': 'glvar',
148,150c148,150
< 'NAME': 'glvar_data',
< 'USER': 'uidx',
< 'PASSWORD': '',
---
> 'NAME': 'glvar_data',
> 'USER': 'glvar',
> 'PASSWORD': '',
239a240
>
243a245
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/56dffe09-d271-42a9-82fe-0ade0afbbd04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: DB Router not working on production machine, works on dev.
The problem turned out to be an bug with an custom manager class based on djorm_pgfulltext search mixin. I'd found an issue with it last week, and patched in the development environment but forgotten to patch the other machine. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/f9a2cd3c-2ac2-4ebb-8873-85f1eb298d19%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
