Url logic

[giuliano . bertoletti]

 
Hello,
 
I'm wondering how you would you organize the url layout in a following 
scenario
 
Suppose I've a table of Authors and for each author a list of books.
A book can have only one author, so I link the author with a foreign key.
 
Now I could point to a particular author with a url like this (to show the 
details)
 
/mylibrary/author/32
 
I wish to put a button to add a new book and would like the CreateView 
derived class handling the request to collect the author id (32 in this 
case) so my form would automatically set the foreign key and make it 
unchangeable from the client browser.
 
Now the questions are:
 
1) would you oranize the url in a way like this?   (notice that 32 is the 
author id)
/mylibrary/book/32/addnewbook
 
2) how do I extract the slug within my BookNew (derived from CreateNew)?
url(r'^book/(?P\d+)/addnewbook, BookNew.as_view()),
 
seems not avaliable as in the context/template: {{ slug }}
 
Cheers,
Giulio.
 
 
 

-- 
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/dd239b7e-a0fd-46ba-8558-4e5ef75c2f75%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Django Debug Toolbar 1.0 beta released

[Aymeric Augustin]

Hello,

I'm happy to annonce that we're almost ready to release version 1.0 of the 
Debug Toolbar! Now we need your help to try the beta:
https://github.com/django-debug-toolbar/django-debug-toolbar/releases/tag/1.0-beta

The documentation is available on Read the Docs — make sure you read the 
"latest" version as there are many changes since 0.11:
http://django-debug-toolbar.readthedocs.org/en/latest/

Note that the setup process is different from previous versions:
http://django-debug-toolbar.readthedocs.org/en/latest/installation.html#quick-setup

Please report issues on GitHub:
https://github.com/django-debug-toolbar/django-debug-toolbar/issues

If no major problems are found, we'll release 1.0 in one week.

Here are the main changes from version 0.9.x and earlier. (Versions 0.10 
and 0.11 were transitory versions leading to 1.0; they were released to 
validate some choices before committing to support them for the lifetime of 
1.x.)

- Panels are now rendered on demand, solving the "20MB HTML page" problem
- Panels can be individually disabled from the frontend, in case a panel 
degrades performance severely on a page
- Interception of redirects can be toggled from the frontend
- The handle can be dragged along the right side, in case it hides exactly 
the part of the page you're working on :-) 
- Static files are managed with django.contrib.staticfiles, solving a 
series of URL-related issues
- The setup process was rewritten, to provide a simplified automatic setup 
and an optional explicit setup
- Panels and settings received shorter or better names
- A stable API for third-party panels is documented
- The core of the toolbar was simplified drastically and almost all the 
code was refactored into panels
- The toolbar was made compatible with all current versions of Django and 
Python, including Python 3.
- The test suite was expanded and gained Selenium tests
- Dozens of bugs were fixed

I hope you'll like it!

-- 
Aymeric.

-- 
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/2d498dbe-3880-4986-9dc6-a4f7a68ed1b6%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Url logic

[Drew Ferguson]

Hi

You can get at components passed in the url in views like this

class AuthorView(DetailView):
  model = Author

  def get_context_data(self, **kwargs):
context = super(AuthorView, self).get_context_data(**kwargs)
slug = self.kwargs['slug']

So if you are adding a book you can do something similar 

class BookCreate(CreateView)
  model = Book

  def get_initial(self):
initials = super(BookCreate, self).get_initial()
initials['author'] = self.kwargs['slug']

and if you want to return to the author after creating the book

  def get_success_url(self):
slug = self.kwargs['slug']
return reverse('author', kwargs={'slug': slug})

Although you can build up a complicated url like this

r'^author/(?P\d+)/book/(?P\d+)/edit$', 
view=BookEdit.as_view(),
name='bookedit'),

and still access the url components like
  aid = self.kwargs['aid']
  pk = self.kwargs['pk']

it means often over-riding get_queryset, get_context_data, etc just to get
at the components to reconstruct urls so you can navigate between
views and of course the url becomes fragile if you can change the author of
a book or a book has several authors
I prefer to avoid this and edit books under their own url tree like

r'^book/(?P\d+)/edit$', 
view=BookEdit.as_view(),
name='bookedit'),

This keeps the view much simpler.
 
You can still easily move between the two models or include related
material using "related_names" on the model's ForeignKey

so if in models.Book we had

  author = models.ForeignKey('Author', related_name='books')

in your Author templates you can do

  {% for book in author.book_set.all %}
  {% end for %}

or just

  {{ author.book_set.count }}

https://docs.djangoproject.com/en/1.5/topics/db/queries/#backwards-related-objects

On Sun, 15 Dec 2013 01:20:17 -0800 (PST)
giuliano.bertole...@gmail.com wrote:

>  
> Hello,
>  
> I'm wondering how you would you organize the url layout in a following 
> scenario
>  
> Suppose I've a table of Authors and for each author a list of books.
> A book can have only one author, so I link the author with a foreign key.
>  
> Now I could point to a particular author with a url like this (to show
> the details)
>  
> /mylibrary/author/32
>  
> I wish to put a button to add a new book and would like the CreateView 
> derived class handling the request to collect the author id (32 in this 
> case) so my form would automatically set the foreign key and make it 
> unchangeable from the client browser.
>  
> Now the questions are:
>  
> 1) would you oranize the url in a way like this?   (notice that 32 is
> the author id)
> /mylibrary/book/32/addnewbook
>  
> 2) how do I extract the slug within my BookNew (derived from CreateNew)?
> url(r'^book/(?P\d+)/addnewbook, BookNew.as_view()),
>  
> seems not avaliable as in the context/template: {{ slug }}
>  
> Cheers,
> Giulio.
>  
>  
>  
> 



-- 
Drew Ferguson
AFC Commercial
http://www.afccommercial.co.uk

-- 
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/20131215132229.28d8701c%40blacktav.fergiesontour.org.
For more options, visit https://groups.google.com/groups/opt_out.

SelectDateWidget doesn't work after reload

[voger]

I am trying to make a sign up form and there I want to get the users 
birth date. I want to use the select date widget. in my models.py I have 
set a model field:


birth_date = models.DateField(verbose_name='Birth Date')

and my forms.py looks like this:

from django import forms
from django.forms.extras import SelectDateWidget
from models import UserProfile
import datetime

yearNow = datetime.date.today().year


class UserProfileForm(forms.ModelForm):
class Meta:
model = UserProfile

localized_fields = ('gender', 'birth_date', 'has_accepted_tos', 
'is_18_or_older')

widgets = {
'birth_date': SelectDateWidget(years=reversed(range(yearNow 
- 100, yearNow - 18)))

}

The problem is that I don't always get a list of years. The first time I 
access the form it works fine. If I reload the form I get a list for the 
months, for the days but the list of the years just shows a '---'.


How can I fix 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/52ADC123.8000904%40yahoo.gr.
For more options, visit https://groups.google.com/groups/opt_out.

View decorators before CSRF verification?

[Dalton Hubble]

I have a function based view that should only respond to GET and HEAD 
requests so I used the @require_safe decorator.

@require_safe
def myview(request):
# logic

so the expected response from a POST request is a 405 Response Not Allowed.

Using Postman to send a POST to the corresponding url, I actually get 
Forbidden 403, CSRF Verification Failed since the default 
'django.middleware.csrf.CsrfViewMiddleware' is being used in 
MIDDLEWARE_CLASSES to protect all views. This must be happening because the 
CSRF middleware checks occur before view specific decorator function checks 
like @require_safe, @require_GET, etc.

Is this something to be bothered about? This is a request for advice and 
discussion rather than debugging a particular problem. I think I would 
prefer if there were a way for Django to check for view decorator 
compliance first because I think a 405 response is more descriptive and 
appropriate for the attempted action. 

However, if there were some middleware to check view decorators and that 
middleware class was ordered earlier than the CsrfViewMiddleware, caution 
would be needed - Django builtin view 
decorators seem 
safe, but user defined view decorators may allow POSTs without checking the 
csrftoken. Thoughts?

-- 
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/3fd55d48-bced-429b-9748-c225250ef549%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Making sure I'm not missing out on some must have Django apps

[Some Developer]

Right so it has been quite awhile since I updated my list of must have 
Django apps. I was wondering if anyone had any suggestions?


Currently I use the following in all my Django projects:

Django Debug Toolbar
debug_toolbar_htmltidy
inspector_panel
debug_toolbar_user_panel
South
Django Compressor

Any other apps that I should be using? I'm looking for general purpose 
apps rather than specific apps as I can find the specific ones when I 
need them.


--
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/52ADDC34.3060306%40googlemail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Installing Django

[Frederick Miller]

Thank you, Mulianto.

On Friday, December 13, 2013 1:10:04 AM UTC-5, Mulianto wrote:
>
> Frederick,
>
> Python installer on windows by default install in c:\python 2.x\
>
> And all package like django and others will be under python folder install 
> in libs\site-package\
>
> Better look to use virtenv so you can create a different environment for 
> different project.
>
> Thanks
> Mulianto
> Blog - Http://muliantophang.blogspot.com
>
>
> Sent from my iPhone
>
> On 13 Des 2013, at 11:17, Mike Dewhirst > 
> wrote:
>
> Frederick
>
> On Windows, the easiest (decision-less) way to install Django is using pip 
> or easy-install. Get pip first if you haven't done so already. Django will 
> then end up in exactly the right place and work faultlessly. I recommend it.
>
> Virtualenv becomes important when you want to run multiple separate Python 
> projects (such as Django projects) but it is a complication you can do 
> without if you are just starting. For example, you might have different 
> projects which absolutely require different versions of (say) Python while 
> you are migrating a project from Python 2.7 to 3.x. Or you might be 
> committed to maintaining multiple versions of the same software and they 
> have different 3rd party app requirements between versions.
>
> VirtualenvWrapper makes manipulating Virtualenv easier but it doesn't 
> appear to be available for Windows.
>
> So, Django will end up in the right place if you use pip. If you install 
> Virtualenv and activate it *then* use pip to install Django, it will also 
> end up in the right place but only for the activated (virtual) environment. 
> This is how you can install different versions of software in different 
> virtual environments.
>
> The real answer to your question is "you shouldn't care".
>
> Mike
>
> On Friday, December 13, 2013 8:55:50 AM UTC+11, Frederick Miller wrote:
>>
>> For Windows XP, should Django be installed under the Python27 folder?  Or 
>> should Django be on the root of the C: drive?
>>  
>> Frederick Miller
>>
>
>
>  
>
> -- 
> 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/3a5619ca-f314-4229-bd97-030b054118d7%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
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/c08b4f89-91b2-40bc-a225-e36f38e1bc9c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Installing Django

[Frederick Miller]

Thank you, Mike.

On Thursday, December 12, 2013 10:17:39 PM UTC-5, Mike Dewhirst wrote:
>
> Frederick
>
> On Windows, the easiest (decision-less) way to install Django is using pip 
> or easy-install. Get pip first if you haven't done so already. Django will 
> then end up in exactly the right place and work faultlessly. I recommend it.
>
> Virtualenv becomes important when you want to run multiple separate Python 
> projects (such as Django projects) but it is a complication you can do 
> without if you are just starting. For example, you might have different 
> projects which absolutely require different versions of (say) Python while 
> you are migrating a project from Python 2.7 to 3.x. Or you might be 
> committed to maintaining multiple versions of the same software and they 
> have different 3rd party app requirements between versions.
>
> VirtualenvWrapper makes manipulating Virtualenv easier but it doesn't 
> appear to be available for Windows.
>
> So, Django will end up in the right place if you use pip. If you install 
> Virtualenv and activate it *then* use pip to install Django, it will also 
> end up in the right place but only for the activated (virtual) environment. 
> This is how you can install different versions of software in different 
> virtual environments.
>
> The real answer to your question is "you shouldn't care".
>
> Mike
>
> On Friday, December 13, 2013 8:55:50 AM UTC+11, Frederick Miller wrote:
>>
>> For Windows XP, should Django be installed under the Python27 folder?  Or 
>> should Django be on the root of the C: drive?
>>  
>> Frederick Miller
>>
>
>
>  
>

-- 
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/64d15c36-c638-4e8c-a127-8be41a09d1a5%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Installing Django

[Frederick Miller]

Thank you, Thomas.

On Thursday, December 12, 2013 5:08:19 PM UTC-5, Thomas wrote:
>
> On 12/12/13 1:55 PM, Frederick Miller wrote: 
> > For Windows XP, should Django be installed under the Python27 folder?   
> > Or should Django be on the root of the C: drive? 
>
> I have no experience with Windows installations, but for other platforms 
> virtualenv and pip are a real help for getting repeatable, consistent 
> installations with a minimum of effort. I believe that is the case for 
> Windows boxes too. 
>
> If you use virtualenv, then you will have a complete python and django 
> installation in a location of your choosing, independent of the system 
> installation areas. 
>
> hth 
>
>   - Tom 
>
> > Frederick Miller 
> > -- 
> > 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/303094d2-2a45-4c56-bcf8-4884e97be365%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/groups/opt_out. 
>
>

-- 
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/9a580d33-a021-45ec-867f-150e271eb14f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Installing Django

[Frederick Miller]

Thank you, Guddu.

On Thursday, December 12, 2013 9:19:40 PM UTC-5, Guddu wrote:
>
> It goes into Lib\site-packages folder.
>
> Regards,
> Anurag
>
>
> On Thu, Dec 12, 2013 at 6:55 PM, Frederick Miller 
> 
> > wrote:
>
>> For Windows XP, should Django be installed under the Python27 folder?  Or 
>> should Django be on the root of the C: drive?
>>  
>> Frederick Miller
>>
>> -- 
>> 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/303094d2-2a45-4c56-bcf8-4884e97be365%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
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/d57a6802-eda0-4621-922f-2a27d0135760%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Making sure I'm not missing out on some must have Django apps

[Sebastian Morkisch]

Some short description of these plugins are appreciated. Maybe a link?

Am Sonntag, 15. Dezember 2013 17:43:32 UTC+1 schrieb Some Developer:
>
> Right so it has been quite awhile since I updated my list of must have 
> Django apps. I was wondering if anyone had any suggestions? 
>
> Currently I use the following in all my Django projects: 
>
> Django Debug Toolbar 
> debug_toolbar_htmltidy 
> inspector_panel 
> debug_toolbar_user_panel 
> South 
> Django Compressor 
>
> Any other apps that I should be using? I'm looking for general purpose 
> apps rather than specific apps as I can find the specific ones when I 
> need them. 
>

-- 
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/63f9e023-d2bc-4904-8036-de93032ab9de%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Making sure I'm not missing out on some must have Django apps

[Lee Hinde]

I googled the list without any problem.

On December 15, 2013 at 2:21:42 PM, Sebastian Morkisch (semo...@googlemail.com) 
wrote:

Some short description of these plugins are appreciated. Maybe a link?

Am Sonntag, 15. Dezember 2013 17:43:32 UTC+1 schrieb Some Developer:
Right so it has been quite awhile since I updated my list of must have
Django apps. I was wondering if anyone had any suggestions?

Currently I use the following in all my Django projects:

Django Debug Toolbar
debug_toolbar_htmltidy
inspector_panel
debug_toolbar_user_panel
South
Django Compressor

Any other apps that I should be using? I'm looking for general purpose
apps rather than specific apps as I can find the specific ones when I
need them.
--
Lee Hinde

-- 
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/etPan.52ae3101.df6a0f2.db5d%40Fifteen.local.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Making sure I'm not missing out on some must have Django apps

[Frank Bieniek]

Hi,
I would add some:
django-userena - user self registration
django-organizations - user and organizations
django-guardian - object level permissions
django-paranoia - paranoid security stuff
django-cache machine / johnny-cache

Thx
Frank

Am 15.12.13 17:43, schrieb Some Developer:
Right so it has been quite awhile since I updated my list of must have 
Django apps. I was wondering if anyone had any suggestions?


Currently I use the following in all my Django projects:

Django Debug Toolbar
debug_toolbar_htmltidy
inspector_panel
debug_toolbar_user_panel
South
Django Compressor

Any other apps that I should be using? I'm looking for general purpose 
apps rather than specific apps as I can find the specific ones when I 
need them.




--
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/52AE3603.6070504%40produktlaunch.de.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Error Doing python manage.py syncdb in django pyBB

[Frank Bieniek]

django.utils.simplejson is deprecated; use json instead.

Hi Alok,
it seems pyBB is not django 1.6 compatible - simplejson got deprecated 
in 1.6


just my 2 cents
Frank


Am 14.12.13 15:15, schrieb Alok Nag:

Hello Experts,

I am newbie to Django/Python. I am trying to setup a forum app using 
pyBB and after following steps mentioned at their website, I am 
getting following error when I am running python manage.py syncdb


[aloknag-mbp15:~/Desktop/forum] aloknag% ./manage.py syncdb

/Library/Python/2.7/site-packages/django_common-0.1.51-py2.7.egg/common/fields.py:6: 
DeprecationWarning: django.utils.simplejson is deprecated; use json 
instead.


  from django.utils import simplejson


*CommandError: One or more models did not validate:*

*pyBB.forum: 'category' has a relation with model 'pybb.models.Category'>, which has either not been installed or is 
abstract.*


*pyBB.forum: Accessor for field 'category' clashes with related field 
'Category.forums'. Add a related_name argument to the definition for 
'category'.*


*pyBB.forum: Reverse query name for field 'category' clashes with 
related field 'Category.forums'. Add a related_name argument to the 
definition for 'category'.*


*pyBB.topic: 'forum' has a relation with model 'pybb.models.Forum'>, which has either not been installed or is abstract.*


*pyBB.topic: Accessor for field 'forum' clashes with related field 
'Forum.topics'. Add a related_name argument to the definition for 
'forum'.*


*pyBB.topic: Reverse query name for field 'forum' clashes with related 
field 'Forum.topics'. Add a related_name argument to the definition 
for 'forum'.*


*pyBB.post: 'topic' has a relation with model 'pybb.models.Topic'>, which has either not been installed or is abstract.*


*pyBB.post: Accessor for field 'topic' clashes with related field 
'Topic.posts'. Add a related_name argument to the definition for 'topic'.*


*pyBB.post: Reverse query name for field 'topic' clashes with related 
field 'Topic.posts'. Add a related_name argument to the definition for 
'topic'.*



Appreciate any insight to fix it.

Thanks,
Alok

--
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/c38a3c9f-27bf-4685-9c3e-8f79f5bb5bbc%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/52AE3759.3090307%40produktlaunch.de.
For more options, visit https://groups.google.com/groups/opt_out.

Initial sql question

[Larry Martell]

My model is named foo, but my tables start with bar_ (I set the table
names in the Meta class in my models). I have an initial sql file in
app/foo/sql/blah.sql to initialize bar_blah, but it is not getting
executed. Is this because of the difference in the model name and
table prefix?

-- 
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/CACwCsY5F77%3DEKFeX%2B%2BBP%3DkHF%2BdzoBPxu4kqi7s7-WWY4NJN2rw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: View decorators before CSRF verification?

[Simon Charette]

Hi Dalton,

> Is this something to be bothered about? This is a request for advice and 
discussion rather than debugging a particular problem. I think I would 
prefer if there were a way for Django to check for view decorator 
compliance first because I think a 405 response is more descriptive and 
appropriate for the attempted action. 

IMO the whole require_http_methods family should be fixed to work with the 
CSRF machinery or at least it should be documented that when using those 
decorators and allowing *non-safe* methods you must exempt the decorated 
views from CSRF checks (@csrf_exempt).

Could you file a 
ticketto report 
this incompatibility?

Simon

Le dimanche 15 décembre 2013 11:38:10 UTC-5, Dalton Hubble a écrit :
>
> I have a function based view that should only respond to GET and HEAD 
> requests so I used the @require_safe decorator.
>
> @require_safe
> def myview(request):
> # logic
>
> so the expected response from a POST request is a 405 Response Not Allowed.
>
> Using Postman to send a POST to the corresponding url, I actually get 
> Forbidden 403, CSRF Verification Failed since the default 
> 'django.middleware.csrf.CsrfViewMiddleware' is being used in 
> MIDDLEWARE_CLASSES to protect all views. This must be happening because the 
> CSRF middleware checks occur before view specific decorator function checks 
> like @require_safe, @require_GET, etc.
>
> Is this something to be bothered about? This is a request for advice and 
> discussion rather than debugging a particular problem. I think I would 
> prefer if there were a way for Django to check for view decorator 
> compliance first because I think a 405 response is more descriptive and 
> appropriate for the attempted action. 
>
> However, if there were some middleware to check view decorators and that 
> middleware class was ordered earlier than the CsrfViewMiddleware, caution 
> would be needed - Django builtin view 
> decorators 
> seem 
> safe, but user defined view decorators may allow POSTs without checking the 
> csrftoken. Thoughts?
>

-- 
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/f62c1cb1-4bc8-45f6-b83f-45d7fb4e9965%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.