Using subclass of RegexValidator for form field
Django 1.3.1 Python 2.7.1 I'm attempting to subclass RegexValidator in my app's validators.py to supply specific 'regex' and 'message' attributes and finding that the field validation I'm attempting does not work. I figure I don't quite understand how to subclass this validator correctly, or else how to implement it as a callable for the 'validators' parameter: # app_name/validators.py from django.core.validators import RegexValidator class PayloadValidator(RegexValidator): regex = 'x' message = u'Valid payload strings contain the letter "x"' # app_name/models.py from app_name import validators class Configuration(models.Model): payload = models.CharField(max_length=64, help_text="Text string to match in health check signature", validators=[validators.PayloadValidator]) ... But when I submit the form, the Configuration instance validates and saves if I enter 'abc' as a value. The following use of URLValidator in my models appears to work correctly, and I had figured I used these validators in the same manner: reference_url = models.URLField(verbose_name="reference URL", blank=True, help_text="(Optional) Reference URL", validators=[URLValidator]) Here, entering "foo" into the field for reference_url outputs a validation error on the form if I enter "foo". What am I missing? Thanks. -- Darren Spruell phatbuck...@gmail.com -- 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.
Handling multiple parameters on URI via GET
I've puzzled my way into a corner. Figuring this will be a
palm-to-forehead moment.
I have a page on my site which is Paginator-ed for the object list.
I'm sticking to the vanilla setup from the docs so when it is in
effect I've got a URI query string of '?page=%d' processed via GET.
I've added a search form to the page and am passing the form data via
GET as well so when a search is in effect I have '?search=%s' on the
URI query. I'm incredibly creative (not) so most of this is done very
closely modeling the approach at
http://www.djangobook.com/en/1.0/chapter07/. I can do either of them
individually just fine, but I can't figure a clean way to have both
pagination and search parameters operate properly across requests as
the user selects next/previous, etc. in the page navigation. It works
if I manually append the missing query parameter to the URI.
How is this typically best handled in Django? I thought about trying
to determine uri query in template and dynamically build the nav links
to include parameters for search and pagination but I didn't figure a
way that wasn't a complete mess.
## view
def list_submissions(request):
"""
Present list of submission logs, paginated.
"""
search_form = SubmissionLogSearchForm()
query = request.GET.get('search', '')
if query:
qset = (
Q(file_name__icontains=query) |
Q(file_md5=query) |
Q(file_sha1=query) |
Q(submitter__username=query)
)
submissionlog_list = SubmissionLog.objects.filter(qset)
else:
submissionlog_list = SubmissionLog.objects.all()
paginator = Paginator(submissionlog_list, 15) # show N logs per page
# Make sure page request is an int. If not, deliver first page.
try:
page = int(request.GET.get('page', '1'))
except ValueError:
page = 1
# If page request () is out of range, deliver last page of results.
try:
submissionlogs = paginator.page(page)
except (EmptyPage, InvalidPage):
submissionlogs = paginator.page(paginator.num_pages)
return render_to_response('avsubmit/submissionlog_pages.html', {
'submissionlogs': submissionlogs,
'search_form': search_form,
}, context_instance=RequestContext(request))
## template
Showing {{ submissionlogs.object_list.count }} submission{{
submissionlogs.object_list.count|pluralize }} of {{
submissionlogs.paginator.count }} total
{% if submissionlogs %}
{{ search_form.as_p }}
File MD5File
NameSubmitterSubmission Date
{% for log in submissionlogs.object_list %}
{% cycle 'row1' 'row2' as rowcolors silent %}
{{ log.file_md5 }}
{{ log.file_name }}
{{ log.submitter }}
{{ log.date_submitted|date:"m/d/Y h:i A" }}
{% endfor %}
{% endif %}
{% if submissionlogs.has_previous %}
<<
{% endif %}
Page {{ submissionlogs.number }} of {{
submissionlogs.paginator.num_pages }}
{% if submissionlogs.has_next %}
>>
{% endif %}
Thx,
--
Darren Spruell
phatbuck...@gmail.com
--
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.
Options for migrating from django.contrib.markup for rST
Greetings, Currently using django.contrib.markup for the restructuredtext filter. 1.5 deprecates the module, and I'd like to start work on replacing it. What libraries are contenders in this space? Aware of this: http://code.google.com/p/django-rstify/ https://github.com/bartTC/django-markup http://packages.python.org/django-markup/ ...although this project seems a bit dated. -- Darren Spruell phatbuck...@gmail.com -- 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.
Seeking pattern for building URLs with all query parameters intact
I've got a handful of applications that feature paginated object lists
as well as a search dialog allowing users to search for simple object
attributes.
What is the common pattern to use in Django apps to build URI query
strings in view code that can preserve parameters for rendering links
in templates? In my case I'd like to handle the following:
1. User searches for string, passed as GET parameter and application
returns paginated object list the spans multiple pages
2. First page contains links for subsequent pages ('page' parameter in
URI query string) and preserves search string (additional 'search'
parameter in URI query string)
So far I've taken key/value pairs out of request.GET and added them to
the context as more_query_params and passed them in to templates. This
seems a little raw and klugey although it works for the simple cases.
There must be a better way. Currently (from a view that returns
paginated object list:
# Determine other parameters from request, provide to template to craft
# smarter URLs that handle concurrent search + pagination (etc.).
if request.method == 'GET':
more_query_params = ''
for key, value in request.GET.items():
if key != 'page':
more_query_params += '&%s=%s' % (key, value)
return render_to_response('submissionlog_pages.html', {
'submissionlogs': submissionlogs,
'search_form': search_form,
'more_query_params': more_query_params,
}, context_instance=RequestContext(request))
What are better ways to handle this?
--
Darren Spruell
phatbuck...@gmail.com
--
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.
Warning about old install when upgrading via pip
Running Django in a virtualenv, have another instance of Django installed system-wide on the system When upgrading the virtualenv Django using 'pip install -U', I see that the old version is uninstalled and the new version installed. At the end of the upgrade, the package reports having been installed over the top of a previous installation. The path to the previous installation shows up as the installation of the system-wide Django. [...] Installing collected packages: Django Found existing installation: Django 1.4.5 Uninstalling Django: Successfully uninstalled Django Running setup.py install for Django changing mode of build/scripts-2.7/django-admin.py from 644 to 755 warning: no previously-included files matching '__pycache__' found under directory '*' warning: no previously-included files matching '*.py[co]' found under directory '*' changing mode of /home/dspruell/venv.d/django-home/bin/django-admin.py to 755 WARNING! You have just installed Django over top of an existing installation, without removing it first. Because of this, your install may now include extraneous files from a previous version that have since been removed from Django. This is known to cause a variety of problems. You should manually remove the /usr/local/lib/python2.7/site-packages/django directory and re-install Django. Successfully installed Django Cleaning up... Is this an expected warning when upgrading Django via pip? And any reason I'd be seeing references to the system-wide install (outside of virtualenv) when I'm doing this upgrade within an active virtualenv? -- Darren Spruell phatbuck...@gmail.com -- 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.
Handling temporary file storage with WizardView
I'm working on a WizardView (django.contrib.formtools) and have a step
that handles a file upload, so I'm setting the file_storage attribute
as required. I'd like the file storage to be a securely created
temporary directory under /tmp so I'm trying to set it to an instance
of tempfile.mkdtemp as below, but I'm stumping myself:
class FileSubmissionWizardView(SessionWizardView):
"Form wizard implementation to handle uploaded samples"
# XXX required. Also, need to take care of removing dir/file in the end.
file_storage = FileSystemStorage(location=mkdtemp(prefix='avsubmit_'))
def done(self, form_list, **kwargs):
# do_something_with_the_form_data(form_list)
# Remove temp upload directory. Eh?
shutil.rmtree(self.file_storage.location)
# Set a message, do a log
return redirect('avsubmit_index')
def process_step_files(self, form):
# do something like set storage extra data
return self.get_form_step_files(form)
My fu is weak, so I'm not certain the right approach here.
file_storage is a class attribute (right?), so I'm not sure this meets
my envisioned goal of having a new temporary directory created for
each uploaded file which I can then delete when finished. Would like
this workflow:
1. User uploads file
2. View invoked to process form, creates _new_ temporary directory for
FileSystemStorage and writes uploaded file to dir. Variable is
populated containing path from mkdtemp() to delete later
3. View processes form
4. View calls shutil.rmtree to delete temporary directory and file
5. View complete
How far off of target am I? Is there a good way to do the above file
resource management using WizardView?
--
Darren Spruell
phatbuck...@gmail.com
--
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.
Executing validation on entry to class-based views
Greetings,
I have an app with a CBV for the main functionality that I'd like to
do some validation on config settings (in settings.py) before carrying
out the view.
My particular view in this case is a FormWizard, but I'd like to know
general to any CBV; what is the correct pattern for doing this? Is
there a standard way to execute validation code upon entering a view
that allows one to access the request object (e.g. for setting
messages) and redirecting clients?
My initial thought was to override __init__() and perform it there but
IIANM it lacks self.request at that point.
What I'd like to implement:
if not settings.SOMEAPP_SETTINGS.get('sender_address'):
messages.error(self.request, "Configuration error:
submission sender address not found. Configure SOMEAPP_SETTINGS in
your project settings file.")
return redirect('index')
--
Darren Spruell
phatbuck...@gmail.com
--
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: Executing validation on entry to class-based views
Hm, yes! Thanks, had forgotten about dispatch().
On Thu, Sep 26, 2013 at 1:24 AM, Daniel Roseman wrote:
> On Thursday, 26 September 2013 07:29:38 UTC+1, dspruell wrote:
>>
>> Greetings,
>>
>> I have an app with a CBV for the main functionality that I'd like to
>> do some validation on config settings (in settings.py) before carrying
>> out the view.
>>
>> My particular view in this case is a FormWizard, but I'd like to know
>> general to any CBV; what is the correct pattern for doing this? Is
>> there a standard way to execute validation code upon entering a view
>> that allows one to access the request object (e.g. for setting
>> messages) and redirecting clients?
>>
>> My initial thought was to override __init__() and perform it there but
>> IIANM it lacks self.request at that point.
>>
>> What I'd like to implement:
>>
>> if not settings.SOMEAPP_SETTINGS.get('sender_address'):
>> messages.error(self.request, "Configuration error:
>> submission sender address not found. Configure SOMEAPP_SETTINGS in
>> your project settings file.")
>> return redirect('index')
>>
>> --
>> Darren Spruell
>> phatb...@gmail.com
>
>
>
> One way would be to override `dispatch()`. You have access to the request
> there and can choose whether to call the super method to do the actual
> dispatching, or redirect instead.
> --
> DR.
>
> --
> 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.
--
Darren Spruell
phatbuck...@gmail.com
--
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/CAKVSOJWnEG_GfonWfA%2BjUAwJ1_AfM8iRaQTLV_9XTSLCYw4mOg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Dealing with redundant JS inclusions at template levels
Spent a bit of time debugging some faulty JavaScript library functionality before I realized that I had included the library at multiple levels in the project - first site-wide in the base template, and then within a app. I think I ran into this: http://stackoverflow.com/questions/4891278/what-is-the-danger-in-including-the-same-javascript-library-twice Is there a good design pattern to this situation, bearing in mind a need to include JS libraries at project level and a desire to use apps that include the same libraries in an attempt to be reusable? Looking at jQuery and Bootstrap for this. -- Darren Spruell phatbuck...@gmail.com -- 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/CAKVSOJVxQ8XF9wojenv6FW53CTHw28xMsD7LCoYas5%2BRchxtBA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dealing with redundant JS inclusions at template levels
On Mon, Sep 30, 2013 at 6:11 AM, Rafael E. Ferrero wrote: > I Dont know your design, usually i include the js library on base template > and my apps templates extend from that... or just put another base template > for every app... > > If you have some example code or tell us why you do that then we be more > helpfull My setup looks like this: Django 1.5 Project/app structure: mysite/ # Project root mysite/ settings.py # INSTALLED_APPS includes 'foo', a reusable app templates/ base.html # Project base template, includes jQuery & # Bootstrap JS for project static/# Static assets for project js/ jquery.js bootstrap.min.js foo/# Reusable app templates/ foo/ index.html # app template, extends 'base.html'. Requires # and includes jQuery and Bootstrap JS for app static/# Static assets for 'foo' app foo/ js/ jquery.js bootstrap.min.js app.js So when 'index.html' from the foo app is rendered, the JS imports look like this: ...because both the project and the reusable app are using jQuery and Bootstrap JS, loading them twice on the same page results in screwed up JS behavior. Also, On Mon, Sep 30, 2013 at 6:18 AM, Dariel Dato-on wrote: > You can consider using Django Sekizai to manage your Javascript and CSS > imports: > > https://django-sekizai.readthedocs.org/en/latest/ Seems interesting, I'll look into it more. To be honest, I think I'm looking for a best practice rather than a solution; how are others managing redundant JS includes when combining their own projects and reusable apps? I imagine there's no app required to do this intelligently. DS > 2013/9/30 Darren Spruell >> >> Spent a bit of time debugging some faulty JavaScript library >> functionality before I realized that I had included the library at >> multiple levels in the project - first site-wide in the base template, >> and then within a app. I think I ran into this: >> >> >> http://stackoverflow.com/questions/4891278/what-is-the-danger-in-including-the-same-javascript-library-twice >> >> Is there a good design pattern to this situation, bearing in mind a >> need to include JS libraries at project level and a desire to use apps >> that include the same libraries in an attempt to be reusable? >> >> Looking at jQuery and Bootstrap for this. >> >> -- >> Darren Spruell >> phatbuck...@gmail.com >> >> -- >> 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/CAKVSOJVxQ8XF9wojenv6FW53CTHw28xMsD7LCoYas5%2BRchxtBA%40mail.gmail.com. >> For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > Rafael E. Ferrero > > -- > 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/CAJJc_8XTE884Y9oCCK1StrtRGxt0Jvd%3DcJiOfboNOdarK%3DC05A%40mail.gmail.com. > For more options, visit https://groups.google.com/groups/opt_out. -- Darren Spruell phatbuck...@gmail.com -- 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/CAKVSOJU9zxR3qJQHFq22X2oRPeTyz38SF%2B9QNfTkuExMiEwGYg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Have browsers broken post-redirect-get? best practice now?
On Thu, Oct 3, 2013 at 6:15 AM, graeme wrote: > I disagree that breaking the back button is always bad. For example suppose > you have a series of forms (i.e. a "wizard"): > > Page 1) fill in form. On POST creates a new Model() and saves it to the > database > 2) do stuff to the object (e.g. add inlines, whatever). > 3) whatever comes next > > At stop two, user clicks back. They then post the form again, and get > another object. On the other hand the page in step 2 can provide a back > button on the page that takes the user back to edit what they entered on > page 1. Which is more useful? I would say the latter - and users may not > then understand that the browser back button and page back button do > different things. Django supports this form wizard behavior in a sane way through Form Wizards: https://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/ In the case of form wizards, each step through the series of forms in the wizard occurs from the same URL, and the API provides users a way to traverse individual forms (steps) in the wizard in a controlled way. If the client uses the browser back button, it drops them back from the URL the form wizard is served from, not to a previous step in the form. DS > On Tuesday, October 1, 2013 8:33:41 PM UTC+5:30, antialiasis wrote: >> >> You should still be able to use the back button; it just shouldn't try to >> post the data again if you do so. Are you getting a prompt about resending >> post data, or are you just talking about being able to use the back button >> at all? If the latter, that's exactly what should happen. Breaking the >> user's back button is bad. >> >> On Tuesday, October 1, 2013 12:41:20 PM UTC, graeme wrote: >>> >>> The Django docs (and a lot else) recommend redirecting after >>> successfully processing a post request (if it changes data). i.e. post, the >>> save stuff to the database, then redirect. >>> >>> Current browsers seem to allow this. I have tried Chromium 28 and 24 on >>> Linux, I user return redirect(...) after the post, and I can still use the >>> back button. >>> >>> Is it my configuration, or is it usual? What is the best practice if this >>> is broken? >>> >>> In some cases I think tracking where the user is (in the session, or >>> using the state of a particular object such as an order model), and >>> redirecting any request for an earlier page in a sequence may be the way to >>> go. Or is this a solved problem that I am too far behind the curve to know >>> about? > > -- > 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/cf0dd1f1-b004-4595-800f-1190ca9f4171%40googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. -- Darren Spruell phatbuck...@gmail.com -- 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/CAKVSOJXf58hvD1H6pu%2BMfo5fUMxKm-VDbncr7hSX7Xm14arP7Q%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Combining use of template tag + filter in same expression
I have a template in which I'm trying to achieve the use of the
'firstof' tag to display whichever of two variables is present, and
the resulting variable filtered through 'truncatewords'. Is there a
way this can be accomplished?
Have tried the following:
{% first of result.meta.summary|truncatewords:12
result.description|truncatewords:12 %}
It doesn't work as I thought it might, instead rendering 'None' in the template.
This construct seems to work as expected if only the last variable is
applied the filter:
{% firstof result.meta.summary result.description|truncatewords:2 %}
Can this be made to work? Or is the combination of firstof and a
filter on more than the last variable unsupported?
Python 2.7.7
Django 1.6.5
--
Darren Spruell
phatbuck...@gmail.com
--
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/CAKVSOJUCLm1b4UBny31Z8MZxMUTxou0GR2WW5HsYn_vjcMvt5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Django image upload not saving
On Thu, Jun 26, 2014 at 10:58 AM, Bobby Gulshan wrote:
> No errors when hitting upload. But the image doesn't appear where I have
> indicated it ought to. Put an absolute path in MEDIA_ROOT and referenced the
> same in (upload_to) param ImageField. Not sure what I am missing.
>
> Model:
>
> class FileUploadHandler(models.Model):
> title = models.CharField(max_length=100)
> file =
> models.ImageField(upload_to='/Python27/Lib/site-packages/django/bin/mideastinfo/wiki/static/')
Your upload_to path looks like an absolute directory, which means that
Django will attempt to store the file in that subdirectory of the path
you've configured for MEDIA_ROOT.
https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.FileField.storage
You want to do like Mario suggested and set 'upload_to' to a relative
path from the MEDIA_ROOT where you want images for that model stored.
--
Darren Spruell
phatbuck...@gmail.com
> View:
>
> from models import Article, Edit
> from forms import ArticleForm, EditForm
> from forms import *
> from PIL import Image
> from models import FileUploadHandler
>
> def image_upload(request):
> if request.method == 'POST':
> form = UploadImageForm(request.POST, request.FILES)
> if form.is_valid():
> FileUploadHandler(request.FILES['image'])
> return render_to_response('wiki/gallery.html')
> else:
> form = UploadImageForm()
> return render_to_response('wiki/gallery.html',
> RequestContext(request, {'form': form}))
>
> --
> 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/29eff052-3181-4e0d-80fc-84fffe6ba029%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
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/CAKVSOJUcPmRRsMXFcYkRje9w8x6ZbO0AxmoOez29q7AhWyeB8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
