Select existing data or creating a new one, with Django forms

[João Luiz Lorencetti]

My model have a field called 'city', it's a foreign key to City model.

The user have the option to select a city in a dropdown menu (Select 
widget), or click in a button and write the name of a new (not present in 
the database) city.

Using a ModelForm, I added an extra field called 'new_city' to my form, 
after that I wrote this clean method: 
https://gist.github.com/dirtycoder/73b70ae6f94acf215e61

I'm new to Django and writing my first "real" web app so I can be missing 
some concept about forms and validation.

Is this the best way to accomplish what I want?

Thanks!

-- 
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/a51ebb41-28ca-480c-bed2-bbd26a72a11e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using git to control the version for an app in my project

[durirompepc]

I refer to a new project (in all the possible meanings). When I use 
*startapp* to create an app, I want to only git (as you would do for any 
other thing) that app, nothing more:

django-admin startproject myproject
cd myproject
python3 manage.py startapp myapp
cd myapp
git init

It's very simple: just versioning something specific.

Anyway, forgot it, I just tested again, and all goes ok. Thanks anyway, and 
I will check that submodule feature in the future.

El miércoles, 22 de julio de 2015, 16:55:14 (UTC+2), durir...@gmail.com 
escribió:
>
> Hello, I'm trying to start a git repo that onyl controls the changes in my 
> app of my Django's project, but I don't get other thing that a VCS error 
> 'cause of a root problem: so I can git the entire project, but not an app 
> separately. Does anyone had this problem before? Is something of Django 
> configuration? It will be sure that I'll have to create a separately git 
> repo for the app?
>
> Thanks.
>

-- 
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/8080e611-427b-422d-a4fe-4ccae9558566%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Use django-console app url in template

[Info Test]

I can access to django-console app with:
127.0.0.1:8000/admin/console.
How to link this with href = "url " in template

-- 
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/7026d6b0-2138-4f30-b7b8-2613ffebfe1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help needed for big django project (crm+shop+cms+autoresponder). What apps shall I build on?

[Avraham Serour]

I know this is an old thread, but I bumped on it while cleaning my inbox.

In any case if it still relevant I recommend looking at treee.io, the
website is down but you can take a look at the code at github (
https://github.com/treeio/treeio)

On Sat, Jun 6, 2015 at 6:55 PM, Luis Zárate  wrote:

> Some useful links:
>
> 1. CRM system
>>
> https://github.com/kunitoki/nublas
>
>  -> client database
>>
>  -> ticket system (client communication including sending emails from
>> backend)
>>
>
> https://github.com/wyldebeast-wunderliebe/mrwolfe
> https://github.com/rossp/django-helpdesk
>
>  2. Shop
>
>>  -> calender booking system
>>
>
> https://github.com/llazzaro/django-scheduler
>
>  -> PDF billing generation
>>
>
> https://github.com/burke-software/django-report-builder
> https://github.com/hirokiky/django-reportmail
> Create your own report using html with https://github.com/ebar0n/xhtml2pdf
>
>
> 3. email autoresponder system
>>
>
> https://github.com/wreckah/django-mailz
>
> 4. CMS functionality would also help
>>
>
> https://github.com/divio/django-cms
> https://github.com/torchbox/wagtail
> https://github.com/stephenmcd/mezzanine
>
> If you need to create addicional software or library then we (my company)
> could offer you commercial support or we could be your partner.
> Contact me privately (see my email in the email header) and talk me about
> your plans.
>
>
> 2015-06-02 11:23 GMT-06:00 ThomasTheDjangoFan <
> stefan.eichholz.ber...@googlemail.com>:
>
>> Hi guys,
>>
>> I am planning on a bigger django project with a lot of functionality.
>>
>> The thing is that I have NO experience with existing django-apps that
>> might fit and definetly need your help.
>>
>> Can you give me a hint which existing (and stable) django-apps I could
>> use as a foundation for my project?
>>
>> Those are the functions that I would like to implement (ordered by
>> priority)
>>  1. *CRM* system
>>  -> client database
>>  -> ticket system (client communication including sending emails from
>> backend)
>>  2. *Shop*
>>  -> calender booking system
>>  -> PDF billing generation
>>  3. email *autoresponder* system
>>  4. *CMS* functionality would also help
>>
>> I would be really thankful if you could guide me to the right direction.
>> Which way shall I go?
>>
>> Kind regards
>> Thomas
>>
>> --
>> 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/14165632-4db7-4d8c-a30e-827c3730ca3a%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> "La utopía sirve para caminar" Fernando Birri
>
>
>  --
> 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/CAG%2B5VyMLi%3DsdDKcrWjSD2JFog9RvR%2BjJKpX-d1HaHYVifuShuw%40mail.gmail.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/CAFWa6tLSfqmEKT9TzA5hukMVNxibifgMd1%2B9vTmqO-uesYZvvw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Why is Admin login template at admin/login.html instead of registration/login.html?

[Carsten Fuchs]

Dear Django fellows,

using Django 1.8.3, I see that the Admin contrib uses the Auth contrib's views (in 
contrib/admin/sites.py). The implementation overrides the auth views' defaults only if 
explicitly specified in the AdminSite object.


For example, changing the user password is implemented in 
contrib.admin.sites.password_change() via django.contrib.auth.views.password_change 
which in turn by default uses template "registration/password_change_form.html", for 
which the Admin contrib brings a matching file.


Only for the login, which is implemented in contrib.admin.sites.login() via 
django.contrib.auth.views.login and which by default uses "registration/login.html", 
does the Admin give a different value, namely "admin/login.html" (if there was no 
explicit user override in the AdminSite object).


Why is the login in this regard an exception?

It seems simpler and more natural to me if the Admin used registration/login.html for 
logins as well.



And a related follow-up question:
Why does the Admin contrib duplicate the Auth views and URLs in the first place?

E.g. when the Admin is installed, there is URL "admin/login/", but as soon as we use our 
own login at settings.LOGIN_URL, there are two login pages (with different templates, 
see above) that serve the exact same purpose.


It seems like this makes it a bit easier getting started with the Admin, but I think 
it's pretty confusing later. Or am I missing / misunderstanding something?


Many thanks and best regards,
Carsten

--
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/55B10048.3010804%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Allow users to submit django form once per day

[Nkansah Rexford]

I want to allow users to submit a django form once, and only once everyday. 
After submitting the form, the form wouldn't even show (server-side 
checkings, I don't want to use JS or client side thing; easily 
'tamper-able')

What is the best way to do so in 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/b310e40f-8baa-449a-bcef-36052d0256a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow users to submit django form once per day

[Robin Lery]

You can save the datetime of the last form submission and check whether its
oneday or not in the view. If its one day then show pass the form or else
dont.

Hope this helps.
On 23 Jul 2015 20:38, "Nkansah Rexford"  wrote:

> I want to allow users to submit a django form once, and only once
> everyday. After submitting the form, the form wouldn't even show
> (server-side checkings, I don't want to use JS or client side thing; easily
> 'tamper-able')
>
> What is the best way to do so in 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/b310e40f-8baa-449a-bcef-36052d0256a5%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/CA%2B4-nGpU8Pmc7ypxZaGACLY1Y34jLsfr75o_Pq2k4-xo35pV%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow users to submit django form once per day

[Maxim Boyarskiy]

You can check how django rest framework solves it:
http://www.django-rest-framework.org/api-guide/throttling/

-- 
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/67332ffc-a6e2-411b-9e70-065b335a3d0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrate a many-to-many field to an explicit intermediate ("through") model?

[Carsten Fuchs]

Am 16.07.2015 um 16:05 schrieb Carsten Fuchs:

Alas... are there any viable alternatives to this?
I'd be very grateful for any hint!   :-)



Anyone please?

Best regards,
Carsten

--
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/55B10E2A.7060809%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Migrate a many-to-many field to an explicit intermediate ("through") model?

[Carl Meyer]

Hi Carsten,

On Thursday, July 16, 2015 at 12:44:55 PM UTC-6, Carsten Fuchs wrote:
>
> Am 2015-07-16 um 18:15 schrieb Gergely Polonkai: 
> > 1) create the "through" model, add it to the migration file 
> > 2) migrate all m2m instances (e.g. iterate over all Bereich objects then 
> > iterate through its users, creating a UserBereichAssignment object for 
> > each (all this done in a migrations.RunPython call) 
>
> Ok. I've never used migrations.RunPython before, but I'm quite confident 
> that I can manage it. 
>

You could also use RunSQL instead of RunPython for this data migration step 
- personally I often find that easier (and almost always more efficient) 
for a simple data migration, since all you need is a SQL query to copy some 
data from one table to another, you don't need any Python conveniences or 
model instances along the way.

But either can work, it really just depends how comfortable you are with 
raw SQL.
 

> Would the migration for step 2) be a separate migration file from step 
> 1), or is the migration file of step 1) edited to cover step 2) as well? 
>

Separate migration. In general you can't put schema alterations and data 
migrations in the same migration file, because then they'll try to run in 
the same transaction, and PostgreSQL at least doesn't like that.

In general, for complex changes, this three-step dance (one migration to 
add the new field/table, a second migration to copy the data, and a third 
migration to remove the old field/table) is very common and the right way 
to do things.
 

> > 3) change the m2m field by adding the through option, and add this 
> > change to the migrations file. 
>
> Same question: Is this supposed to go into a separate migration file or 
> into the common migrations file from above? 
>
> And won't this last step trigger the same error as before? ("... you 
> cannot alter to or from M2M fields, or add or remove through= on M2M 
> fields") ? 
>

This part I'm not sure about without trying it. I'm honestly not sure what 
exactly Gergely was recommending. Based on my reading of the code, the 
error is raised by the schema-editor backend, meaning if you try an 
`AlterField` with this change, you'd hit the error.

Another possibility might be to use the `SeparateDatabaseAndState` 
operation to create a migration that has no effect on the schema, but just 
updates the Python state for the field. Since you've already made the 
necessary db schema changes simply by adding the through model itself, this 
should work fine.

You could also go back and edit the field definition in whichever migration 
initially created it. This would probably work, but it would cause problems 
for any `RunPython` migrations since then that used that field (because now 
they'd try to use the through table instead), including your own data 
migration that you just created prior to this. So probably not a good 
option.
 

> (Not so important, but out of curiosity: This won't get us rid of the 
> old, implicit intermediate table, will it?) 
>

No. You could add another RunSQL migration to remove this table using raw 
SQL.

Overall I think it might be simpler to go with your initial approach. I'd 
first rename the old field to some other temporary name (you don't have to 
update any other code to use this name, as you'll commit all of these 
migrations in one commit, so nothing but the following data migration ever 
needs to know anything about this temporary name), then add the new field 
with through table (using the original field name), then migrate data 
(using either RunPython or RunSQL), then remove the old field. I think this 
will work fine, and it should also remove the old auto-created through 
table.

Good luck! I think this is definitely an area where the migrations system 
could help a bit more.

Carl

-- 
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/e987cf79-358d-4fdc-bac5-5131a19a25c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why is Admin login template at admin/login.html instead of registration/login.html?

[Tim Graham]

The admin login only allows staff users to login so it makes sense to me 
that if you wanted to add regular user login to your site, it should have 
separate URLs.

As for the template issue, it seems to me the admin/template/registration 
templates should be more like admin/login.html and namespaced under admin 
so that if you want to implement a non-admin password reset, you don't have 
a conflict in the template names (see the ticket below for an example). 

https://code.djangoproject.com/ticket/20372

On Thursday, July 23, 2015 at 10:56:08 AM UTC-4, Carsten Fuchs wrote:
>
> Dear Django fellows, 
>
> using Django 1.8.3, I see that the Admin contrib uses the Auth contrib's 
> views (in 
> contrib/admin/sites.py). The implementation overrides the auth views' 
> defaults only if 
> explicitly specified in the AdminSite object. 
>
> For example, changing the user password is implemented in 
> contrib.admin.sites.password_change() via 
> django.contrib.auth.views.password_change 
> which in turn by default uses template 
> "registration/password_change_form.html", for 
> which the Admin contrib brings a matching file. 
>
> Only for the login, which is implemented in contrib.admin.sites.login() 
> via 
> django.contrib.auth.views.login and which by default uses 
> "registration/login.html", 
> does the Admin give a different value, namely "admin/login.html" (if there 
> was no 
> explicit user override in the AdminSite object). 
>
> Why is the login in this regard an exception? 
>
> It seems simpler and more natural to me if the Admin used 
> registration/login.html for 
> logins as well. 
>
>
> And a related follow-up question: 
> Why does the Admin contrib duplicate the Auth views and URLs in the first 
> place? 
>
> E.g. when the Admin is installed, there is URL "admin/login/", but as soon 
> as we use our 
> own login at settings.LOGIN_URL, there are two login pages (with different 
> templates, 
> see above) that serve the exact same purpose. 
>
> It seems like this makes it a bit easier getting started with the Admin, 
> but I think 
> it's pretty confusing later. Or am I missing / misunderstanding something? 
>
> Many thanks and best regards, 
> Carsten 
>
>

-- 
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/5a95a816-0d1f-4117-a581-0d90d017e456%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrate a many-to-many field to an explicit intermediate ("through") model?

[Carsten Fuchs]

Hi Carl,

Am 23.07.2015 um 18:28 schrieb Carl Meyer:

Overall I think it might be simpler to go with your initial approach. I'd first 
rename
the old field to some other temporary name (you don't have to update any other 
code to
use this name, as you'll commit all of these migrations in one commit, so 
nothing but
the following data migration ever needs to know anything about this temporary 
name),


Thanks for clarifying the details regarding renaming! With this, this is the approach 
that I feel the most comfortable with and will try now.


Overall, many thanks for your thoughts and your detailed reply, it's very much 
appreciated and helps a lot!


Best regards,
Carsten

--
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/55B11F7B.1010805%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Why is Admin login template at admin/login.html instead of registration/login.html?

[Carl Meyer]

On 07/23/2015 10:49 AM, Tim Graham wrote:
> The admin login only allows staff users to login so it makes sense to me
> that if you wanted to add regular user login to your site, it should
> have separate URLs.
> 
> As for the template issue, it seems to me the
> admin/template/registration templates should be more like
> admin/login.html and namespaced under admin so that if you want to
> implement a non-admin password reset, you don't have a conflict in the
> template names (see the ticket below for an example).
> 
> https://code.djangoproject.com/ticket/20372

I agree. The auth views expose the option to pass a different template
name. I think the admin should have its own templates namespaced under
`admin/` and pass those template names to the views, rather than
overriding the default auth templates.

Carl

-- 
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/55B12345.1060908%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Why is Admin login template at admin/login.html instead of registration/login.html?

[Carsten Fuchs]

Hi Tim,

many thanks for your reply!

Am 23.07.2015 um 18:49 schrieb Tim Graham:

The admin login only allows staff users to login so it makes sense to me that 
if you
wanted to add regular user login to your site, it should have separate URLs.


I think what confuses me is the fact that (in the Auth app) there is only one User 
model, and the only difference between regular and staff users is the User.is_staff flag.


For example, if a staff user logs out of the Admin, he is logged out as a regular user 
as well. If a regular user logs in via a custom login page, then browses to an Admin 
page, some kind of error report or redirect must occur.


Given this, authentication is like a user-centric, site-wide feature rather than an 
app-specific one, isn't it?



As for the template issue, it seems to me the admin/template/registration 
templates
should be more like admin/login.html and namespaced under admin so that if you 
want to
implement a non-admin password reset, you don't have a conflict in the template 
names
(see the ticket below for an example).

https://code.djangoproject.com/ticket/20372



Well, I am quite happy about the admin using the registration/... templates by default: 
With the view that authentication is user- rather than app-specific, I recently made my 
admin and regular logins look identical, which worked very well.

So ticket 20372 is quite the opposite of my view.  ;-)

In fact, I'd even prefer if the admin came with no auth dependency at all. I'm aware 
that that would make getting started harder (and easily getting started was one of the 
things I was very grateful for while taking my first steps with Django!), but if the 
admin and auth were explicitly separate, it would also remove all confusion both in the 
spirit of ticket 20372 and the opposite of it.


Best regards,
Carsten

--
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/55B12743.7090909%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Buttons

[Jake Rudolph]

Thank you for your response! I am trying to follow AJAX tutorials, and I 
keep running into an issue with the URLConfs. My current admin and index 
page use something like this:

urlpatterns = [
  url(r''^admin/', include(admin.site.urls)),
]

But the when implementing AJAX, everything has said to use something like 
this:

urlpatterns = ('',
  url(r'^ajac$', 'views.ajax')
)

I have tried conforming one to the other format, and tried doing them in 
separate entities, using a urlpatterns list and an extrapatterns list that 
calls patterns. Neither actually worked, and I am unsure how to combine the 
two.

On Wednesday, July 22, 2015 at 6:15:39 PM UTC-7, Alex Heyden wrote:
>
> A fair bit of this is Javascript, which, strictly speaking, is outside the 
> scope of Django.
>
> From what you're saying, it sounds like your button does two things: make 
> a backend database change and make a frontend display change. Ultimately, 
> the action starts with a Javascript event handler. On button click, do work.
>
> On the Django side, you want a view that will capture the change. There's 
> more than a few ways to do this, but if you're just talking about a 
> one-and-done like this and you don't want a bunch of extra libraries, I'd 
> make a simple, dedicated view that takes whatever parameters you need to 
> specify the correct boolean field on POST and returns a JSON response to 
> the effect of {success: [true|false], reason: 'failure reason, if any'}. 
> Don't forget to update your urls.py to reflect the new view.
>
> On the Javascript side, in the registered function, you write code that 
> both posts to your Django view in an Ajax call and, if successful, makes 
> the display change.
>
> On Wed, Jul 22, 2015 at 5:35 PM, Jake Rudolph  > wrote:
>
>> I am trying to make a button on the index page that changes the boolean 
>> field of my object, and then displays that object in a different place on 
>> the page. I am not sure what to put as the action for this button, and 
>> where to put and call the function that will actually change the value in 
>> the database.
>>
>> -- 
>> 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...@googlegroups.com .
>> To post to this group, send email to django...@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/564ecb34-8176-474a-8175-eb1c5b134522%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/b63e2910-02aa-4bc6-8982-71b4ff6d3ddc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Limit initial admin queryset

[Lee Hinde]

I have a model - Registrations. 97% of the time a user wants to see
'todays' registrations when viewing this model in admin. Is there a way to
set the initial display of records, but allow full access thereafter?

The example in admin.get_queryset assumes I want to manage each query. In
my case, I only want to manage those the user doesn't initiate.

-- 
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/CA%2BePoMwrwAyprMorYOxBd8Lhb%2BA9vt3_XaygFD0MhkEFN4XwhA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why is Admin login template at admin/login.html instead of registration/login.html?

[Carl Meyer]

Hi Carsten,

On 07/23/2015 11:41 AM, Carsten Fuchs wrote:
> Am 23.07.2015 um 18:49 schrieb Tim Graham:
>> The admin login only allows staff users to login so it makes sense to
>> me that if you
>> wanted to add regular user login to your site, it should have separate
>> URLs.
> 
> I think what confuses me is the fact that (in the Auth app) there is
> only one User model, and the only difference between regular and staff
> users is the User.is_staff flag.
> 
> For example, if a staff user logs out of the Admin, he is logged out as
> a regular user as well. If a regular user logs in via a custom login
> page, then browses to an Admin page, some kind of error report or
> redirect must occur.
> 
> Given this, authentication is like a user-centric, site-wide feature
> rather than an app-specific one, isn't it?

Sure, the logged-in status of a given session is site-wide. But that
doesn't imply that there must be only a single login page, that always
looks the same and behaves the same. Normally on a Django site (with the
defaults) you'd have an admin login page which only allows staff users
to log in, and redirects them by default to the admin post-login, and is
styled to look like the admin. And you'd have a public login page which
allows any user to login, and redirects them by default to somewhere
else (not the admin) post-login.

There's no contradiction between having two (or more!) such login pages,
and the fact that once a user logs in with either of those login pages,
they are logged in to the whole site.

Of course it's _possible_ to have just a single login page instead, if
you want that, but it's not at all clear to me that that's better. I
prefer to keep the admin relatively separate from the public site.

And I think the same is true for password-reset etc. I'd prefer to leave
the admin with its own pages, styled consistently with the rest of the
admin, and design my own pages for public users, consistent with the
design of the rest of the public site.

>> As for the template issue, it seems to me the
>> admin/template/registration templates
>> should be more like admin/login.html and namespaced under admin so
>> that if you want to
>> implement a non-admin password reset, you don't have a conflict in the
>> template names
>> (see the ticket below for an example).
>>
>> https://code.djangoproject.com/ticket/20372
>>
> 
> Well, I am quite happy about the admin using the registration/...
> templates by default: With the view that authentication is user- rather
> than app-specific, I recently made my admin and regular logins look
> identical, which worked very well.
> So ticket 20372 is quite the opposite of my view.  ;-)

Presuming we made the admin use its own templates for all of this, you
could achieve what you want by also overriding the admin templates and
just making them inherit everything from your templates. A tiny bit of
boilerplate, but not much.

I think the preferable default is to have the admin separate.

Carl

-- 
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/55B12D5A.50409%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Allow users to submit django form once per day

[Nkansah Rexford]

>
> You can save the datetime of the last form submission and check whether 
> its oneday or not in the view. If its one day then show pass the form or 
> else dont.
>
> Hope this helps.
>

I do know I have to save the date stamp, but the question is Where? On the 
model class, the user class, or in a text file?

-- 
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/deec0350-fbae-4306-8f98-f7f2cb856bbd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow users to submit django form once per day

[Carl Meyer]

On 07/23/2015 01:32 PM, Nkansah Rexford wrote:
> You can save the datetime of the last form submission and check
> whether its oneday or not in the view. If its one day then show pass
> the form or else dont.
> 
> Hope this helps.
> 
> 
> I do know I have to save the date stamp, but the question is Where? On
> the model class, the user class, or in a text file?

The database. Either a new field on a user or profile model, or on the
model the form is for, or a new model specifically for this purpose.
Hard to say with the info you've given so far which of those makes most
sense for your case, any of them could work. (E.g. "on the model the
form is for" only makes sense if that model is "owned" by a single user,
not edited by multiple users.)

Saving persistent data on a Python class (if that's what you meant by
"the model class" or "the user class") doesn't work; you'll lose the
data if the server restarts.

Text file would work, but that's a lot of hassle to no good end when you
have the database available, whose entire purpose is to store persistent
data for you.

Carl

-- 
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/55B14265.9000200%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Migrate a many-to-many field to an explicit intermediate ("through") model?

[Gergely Polonkai]

Hello,

I'm sorry, I was not around my mailbox lately.

Yes, you are right, my attempt is not the solution to your problem; it
seems that this m2m field really cannot be modified like this. With some
slight modifications, though, it may be.

1) create the through table
2) migrate data with RunPython — if you want to be portable, stay with
RunPython instead of RunSQL
3) delete the ManyToManyField
4) recreate the ManyToManyField with the through option

All this can (and I think, should) go into the same migration file.
Meanwhile it might worth a question to the devs (or a more thorough search
on the topic) to understand why you can't switch from a simple m2m field to
one with a through option.

Best,
Gergely
On 23 Jul 2015 19:08, "Carsten Fuchs"  wrote:

> Hi Carl,
>
> Am 23.07.2015 um 18:28 schrieb Carl Meyer:
>
>> Overall I think it might be simpler to go with your initial approach. I'd
>> first rename
>> the old field to some other temporary name (you don't have to update any
>> other code to
>> use this name, as you'll commit all of these migrations in one commit, so
>> nothing but
>> the following data migration ever needs to know anything about this
>> temporary name),
>>
>
> Thanks for clarifying the details regarding renaming! With this, this is
> the approach that I feel the most comfortable with and will try now.
>
> Overall, many thanks for your thoughts and your detailed reply, it's very
> much appreciated and helps a lot!
>
> Best regards,
> Carsten
>
> --
> 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/55B11F7B.1010805%40cafu.de.
> 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/CACczBU%2BYcmaxdqr7q-i%3DY1Xe3U%2BE0BqUF%2BqbBWFhthQoWFOg7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrate a many-to-many field to an explicit intermediate ("through") model?

[Carl Meyer]

Hi Gergely,

On 07/23/2015 02:27 PM, Gergely Polonkai wrote:
> Yes, you are right, my attempt is not the solution to your problem; it
> seems that this m2m field really cannot be modified like this. With some
> slight modifications, though, it may be.
> 
> 1) create the through table
> 2) migrate data with RunPython — if you want to be portable, stay with
> RunPython instead of RunSQL

Yes, this is true. Don't use RunSQL if you want your code to be portable
between database backends. (For most of my non-reusable-apps code, I
take great advantage of Postgres-specific features and don't care at all
about cross-database portability.)

> 3) delete the ManyToManyField
> 4) recreate the ManyToManyField with the through option
> 
> All this can (and I think, should) go into the same migration file.

Hmm. I'm almost sure I've had problems in the past with trying to do
schema alterations and data migration in the same migration file (thus
same transaction), but with a simple test just now it seems to work OK
on Postgres. I'll have to start trying to combine migrations like this
more often and see how it goes.

> Meanwhile it might worth a question to the devs (or a more thorough
> search on the topic) to understand why you can't switch from a simple
> m2m field to one with a through option.

Just because it's a bit complex to implement, and nobody has implemented
it yet.

Carl

-- 
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/55B15070.8000707%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Thumbnails In Django

[divyanshi kathuria]

On Wednesday, July 22, 2015 at 3:12:47 AM UTC+5:30, Robin Lery wrote:
>
> Yes. I would like to add easy-thumbnails too. Both are great! 
>
I used easy-thumbnails. But it doesn't store the thumnails in my database. 
I want three fields to get populated on loading the image : image, 
thumbnail_large,thumbnail_small. These apps just store the thumbnails in 
folders. 

-- 
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/7e75e3eb-e694-4731-b843-c06b4afeae45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How to use Python Requests Module to upload images to Django Application?

[Ted Thomas]

I am developing a django application that primarily uses web browsers to 
upload scientific data that includes some image files.  Currently, the 
application works fine when Firefox or Chrome are used.  Both images and 
other data are correctly uploaded.

Occasionally users need to upload larger amounts of data, so I want to 
automate this using Python's Requests module.  My python program currently 
uploads non-image data, but Django is not receiving the image files.   This 
may be because I am not setting HTTP-headers correctly.

When the user agent is Firefox, requests received by Django include headers 
like:

  HTTP_ACCEPT_ENCODING   gzip, deflate
  HTTP_ACCEPT   
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

When the user agent is my standalone program, only:

  HTTP_ACCEPT_ENCODING   identity

My questions are:

  1) What HTTP-headers is Django expecting?

  2) Should I be gzipping the image files?

  3) What is the correct way to do this?

A code snippet from my standalone program follows.

==
# loop to get messages from console
while True:
   message = input("Enter msg string: ")
   filename= input("Enter filename (or blank): ")

   # GET
   print("--- GET upload_msg")
   # Create a GET request (but do don't sent it)
   req   = Request('GET', upload_msg_url, data= {})
   # Send request
   forms_dct= get_response(req)

   # modify forms_dct from GET, and use in next get_response()
   forms_dct['message_str'] = message

   # open file for upload
   fobj = open(filename,'rb')
   # modify forms_dct from GET, and use in next get_response()
   forms_dct['photo'] = filename

   # Create files dictionary
   files_dct = {filename:fobj}

   # POST
   print("--- POST upload_msg")
   # Create a POST request (but do don't sent it)
   req   = Request('POST', upload_msg_url, data= forms_dct, files= 
files_dct)
   # Send request
   forms_dct   = get_response(req) 

   # close file
   fobj.close()
==

Thanks.






-- 
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/79a3f85c-b85a-44d1-b7d6-bf150eb35978%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django : DRF Token based Authentication VS JSON Web Token

[Ankit Agrawal]

 
   
Hi everyone,


I am building a real world application where users will access the app 
primarily from Android, iOS devices as well as Desktops.

>From my elementary research, I have realized that token based 
authentication mechanism is more better and elegant for client-server 
models as compared to session based authentication.


In Django, I have found two popular ways to do this -

   1. 
   
http://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication
   2. http://getblimp.github.io/django-rest-framework-jwt/

>From what I understood, option 2] is an extension of 1] except that the 
Token is in the form of JSON(serialized). I would like to understand what 
other differences there are between option 1] and 2] and the 
advantages/disadvantages of choosing either.

-- 
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/11204a7d-a582-40bd-a9ba-e06abe23afff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

retrieve row with maximum field value django

[Nkansah Rexford]

Say I have a model

class MyModel(models.Model)
name = models.CharField(max_length=20)
age = models.IntergerField()

How can I find the maximum based on the 'Age' field number and retrieve 
that whole object? I understand aggregates allows me to find and retrieve 
the maximum number when given a field to run on, but I only get the maximum 
number ONLY and not the other items in the row.

Does django have something that allows to find the maximum (or minimum) 
value of a database field, then retrieve whole row in the query?

-- 
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/5fc15560-93f6-4ba2-a30f-287f1fe76713%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to use Python Requests Module to upload images to Django Application?

[Ted Thomas]

My Python code started working after I changed on line.

Changing:
 files_dct = {filename:fobj}
to:
files_dct = {('photo',(filename, fobj,'image/jpg'))}

Now it works.  My conjecture about the need for different HTTP-headers was 
wrong.  The working code has not changed the headers received by Django.

I must say, the Requests module documentation is very opaque!

I made this change based on a guess while reading the docs about sending 
multiple files.  I can't say I understand what going on.

Please comment on the right way to do this.  



>
>

-- 
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/ab20873c-7e7e-4817-82f8-1a691a2cfa14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django Model field : Ordered List of Foreign Keys

[Ankit Agrawal]

I have a `Route` model which should store an ordered list of stops along 
that route. How should I go about modeling this relation?

class Stop(models.Model):
name = ..
latitude = ..
longitude = ..

class Route(models.Model):
stops_list = # Ordered list of stops on the route


-- 
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/72e84a42-a0ad-4dcb-bfcd-948d1050c8e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Model field : Ordered List of Foreign Keys

[Alex Heyden]

There are options, but here's what I'd do:

class Stop(models.Model):
  name = models.TextField()  #use CharField if not using Postgres
  latitude = models.DecimalField()
  longitude = models.DecimalField()
  route = models.ForeignKey('Route')
  sequence = models.IntegerField()

  class Meta:
unique_together = (('route', 'sequence'), )
ordering = ['route', 'sequence']

class Route(models.Model):
  # I'm sure there's something you want to know about the route,
  # so add it here.

>>> stops = Route.objects.first().stop_set


On Thu, Jul 23, 2015 at 9:21 PM, Ankit Agrawal  wrote:

> I have a `Route` model which should store an ordered list of stops along
> that route. How should I go about modeling this relation?
>
> class Stop(models.Model):
> name = ..
> latitude = ..
> longitude = ..
>
> class Route(models.Model):
> stops_list = # Ordered list of stops on the route
>
>
>  --
> 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/72e84a42-a0ad-4dcb-bfcd-948d1050c8e2%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/CA%2Bv0ZYXhHwWHAovVC7RFhD6bm7Nmz%2BCSQrSSaSeqCZC9g7ybUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: retrieve row with maximum field value django

[James Schneider]

Use a combination of order_by('-age') and first() on your query set.

MyModel.objects.order_by('-age').first()

https://docs.djangoproject.com/en/1.8/ref/models/querysets/#order-by

Obviously that only pulls the "first" object even if multiple objects have
that same age, so you may need additional filter() and sorting criteria.

-James
On Jul 23, 2015 6:58 PM, "Nkansah Rexford"  wrote:

> Say I have a model
>
> class MyModel(models.Model)
> name = models.CharField(max_length=20)
> age = models.IntergerField()
>
> How can I find the maximum based on the 'Age' field number and retrieve
> that whole object? I understand aggregates allows me to find and retrieve
> the maximum number when given a field to run on, but I only get the maximum
> number ONLY and not the other items in the row.
>
> Does django have something that allows to find the maximum (or minimum)
> value of a database field, then retrieve whole row in the query?
>
> --
> 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/5fc15560-93f6-4ba2-a30f-287f1fe76713%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/CA%2Be%2BciXVrBNhxfJ%3D-Z_A2LpFCsQpikyqt-HS-3pW2jJNXUTwDA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django : DRF Token based Authentication VS JSON Web Token

[Gergely Polonkai]

Hello,

after a quick read I cannot find any essential differences between the two,
in regards of authentication. JWT, however, is much more fine grained and
has a bunch of token manipulation options.

Best,
Gergely
On 24 Jul 2015 03:01, "Ankit Agrawal"  wrote:

>
>Hi everyone,
>
>
> I am building a real world application where users will access the app
> primarily from Android, iOS devices as well as Desktops.
>
> From my elementary research, I have realized that token based
> authentication mechanism is more better and elegant for client-server
> models as compared to session based authentication.
>
>
> In Django, I have found two popular ways to do this -
>
>1.
>
> http://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication
>2. http://getblimp.github.io/django-rest-framework-jwt/
>
> From what I understood, option 2] is an extension of 1] except that the
> Token is in the form of JSON(serialized). I would like to understand what
> other differences there are between option 1] and 2] and the
> advantages/disadvantages of choosing either.
>
> --
> 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/11204a7d-a582-40bd-a9ba-e06abe23afff%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/CACczBU%2BOuayzoNLSX%2BQTbCdXBT0xsUzb%3DCRXh%3DyCzj%2BF4yvWZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.