Migrating to class-based views and django.core.urlresolvers.reverse
I have been tracking the development of class-based views for a few
weeks now, and am just starting to adapt some of my work-in-progress
sites. This post is in a bit of a grey area between django-users and
django-developers, but I'm curious what is suggested for sites that
make heavy use of django.core.urlresolvers.reverse() and {% url %} in
templates.
Obviously with the old function-based views, we could simply do this:
from django.core.urlresolvers import reverse
def my_view(request):
... do something useful ...
return response
my_view_url = reverse('my_app.views.my_view')
And likewise we could also reference that view using the {% url %} tag
in templates.
What is the recommendation for using reverse() and {% url %} when we
migrate to class-based views? So fat the only solution I have come up
with is naming the the URL patterns in urls.py, for example:
urlpatterns = patterns('',
(r'^$', TemplateView.as_view(template_name='main/index.html'), {},
'home'),
)
In the above case, we can now reverse('home') or {% url "home" %} -
but is this the only way? If so, one would have to give some careful
thought to the names of the URL patterns, so that it was readily
obvious what view each named URL actually was. For example, one might
end up using names like "myapp.IndexView" - a pseudo-hierarchical
naming scheme, to essentially bring us back to the place we were with
function-based view names.
I look forward to people's ideas about this...
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Migrating to class-based views and django.core.urlresolvers.reverse
Hi Daniel,
I'm not core developer, but I think
http://docs.djangoproject.com/en/dev/topics/http/urls/#defining-url-namespaces
should be used.
you can use reverse("yournamespace:someview"), and it's also cool to
do things like this in settings.py:
reverse_lazy = lazy(reverse, str)
LOGIN_REDIRECT_URL = reverse_lazy('yournamespace:your_main_page')
Perhaps it's not advertised as it should, and people continue to
invent their tricky namespace schemes...
On Tue, Dec 7, 2010 at 3:42 PM, Daniel Swarbrick
wrote:
> I have been tracking the development of class-based views for a few
> weeks now, and am just starting to adapt some of my work-in-progress
> sites. This post is in a bit of a grey area between django-users and
> django-developers, but I'm curious what is suggested for sites that
> make heavy use of django.core.urlresolvers.reverse() and {% url %} in
> templates.
>
> Obviously with the old function-based views, we could simply do this:
>
> from django.core.urlresolvers import reverse
>
> def my_view(request):
> ... do something useful ...
> return response
>
> my_view_url = reverse('my_app.views.my_view')
>
> And likewise we could also reference that view using the {% url %} tag
> in templates.
>
> What is the recommendation for using reverse() and {% url %} when we
> migrate to class-based views? So fat the only solution I have come up
> with is naming the the URL patterns in urls.py, for example:
>
> urlpatterns = patterns('',
> (r'^$', TemplateView.as_view(template_name='main/index.html'), {},
> 'home'),
> )
>
> In the above case, we can now reverse('home') or {% url "home" %} -
> but is this the only way? If so, one would have to give some careful
> thought to the names of the URL patterns, so that it was readily
> obvious what view each named URL actually was. For example, one might
> end up using names like "myapp.IndexView" - a pseudo-hierarchical
> naming scheme, to essentially bring us back to the place we were with
> function-based view names.
>
> I look forward to people's ideas about this...
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
Best regards, Yuri V. Baburov, Skype: yuri.baburov, MSN: bu...@live.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
call_command retval
I think call_command should return something significant to let the caller know if the command was successful or not. Another issue ralated to this is: having an error retcode when calling management commands from commandline The problem now is that for instance loaddata swallows all exceptions and only spits them out to stderr without exiting sys.exit(1) that's not good if you use loaadata command from a script. Do you agree? should I submit a ticket (I could not find any on django trac)? Marco -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feedback required: #14799 -- Problem with setting up test databases
Maybe unrelated... have you had a look at #14662? Marco -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feedback required: #14799 -- Problem with setting up test databases
On Tue, Dec 7, 2010 at 11:21 PM, mpaolini wrote: > Maybe unrelated... > > have you had a look at #14662? It's related, but in the sense that it's the manual manifestation of what #14799 needed to correct. The contenttype and auth post_syncdb handlers ignore --db by design -- they should be (and are) using the router to determine where content types should be written. If running `sycndb` on `other` causes an error because `default` doesn't exist, then that means you have a dependency in your database setup, and you need to run `sycndb` on `default` first. #14799 was the manifestation of this problem in the test suite. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feedback required: #14799 -- Problem with setting up test databases
Russell Keith-Magee ha scritto: On Tue, Dec 7, 2010 at 11:21 PM, mpaolini wrote: Maybe unrelated... have you had a look at #14662? It's related, but in the sense that it's the manual manifestation of what #14799 needed to correct. The contenttype and auth post_syncdb handlers ignore --db by design -- they should be (and are) using the router to determine where content types should be written. If running `sycndb` on `other` causes an error because `default` doesn't exist, then that means you have a dependency in your database setup, and you need to run `sycndb` on `default` first. #14799 was the manifestation of this problem in the test suite. Yours, Russ Magee %-) Ok then I'll mark it "invalid", but only after having understood the whole thing thanks for explaining Marco -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Migrating to class-based views and django.core.urlresolvers.reverse
Forgetting namespaces or existing named URL patterns for a moment, the
major difference is that with function-based views, we were giving a
qualified "module.function" parameter to reverse() or {% url %}.
How can we do that with class-based views, without naming every URL
pattern? Or is it not possible?
A side question that's been nagging at me during all this is, will
class-based views become the norm, even in places where we weren't
using function-based generic views? I was using direct_to_template()
in 99% of my views, simply because it was a shortcut for the whole
render_to_response('my_template.html', my_data_dictionary,
context_instance=RequestContext(request)) palaver. In most cases I was
still passing an extra_context, but it was a little bit less
typing ;-)
Another question (sorry - maybe these should be separate posts), how
does one go about using the permission_required() decorator with class-
based views, or something like the following:
@user_passes_test(lambda u: u.is_superuser)
def my_superview(request):
...
return response
Sorry if I'm jumping the gun a little bit. I realise this is a dev
version and is still in flux.
On Dec 7, 2:33 pm, "burc...@gmail.com" wrote:
> Hi Daniel,
>
> I'm not core developer, but I
> thinkhttp://docs.djangoproject.com/en/dev/topics/http/urls/#defining-url-n...
> should be used.
>
> you can use reverse("yournamespace:someview"), and it's also cool to
> do things like this in settings.py:
>
> reverse_lazy = lazy(reverse, str)
> LOGIN_REDIRECT_URL = reverse_lazy('yournamespace:your_main_page')
>
> Perhaps it's not advertised as it should, and people continue to
> invent their tricky namespace schemes...
>
> On Tue, Dec 7, 2010 at 3:42 PM, Daniel Swarbrick
>
>
>
>
>
>
>
>
>
> wrote:
> > I have been tracking the development of class-based views for a few
> > weeks now, and am just starting to adapt some of my work-in-progress
> > sites. This post is in a bit of a grey area between django-users and
> > django-developers, but I'm curious what is suggested for sites that
> > make heavy use of django.core.urlresolvers.reverse() and {% url %} in
> > templates.
>
> > Obviously with the old function-based views, we could simply do this:
>
> > from django.core.urlresolvers import reverse
>
> > def my_view(request):
> > ... do something useful ...
> > return response
>
> > my_view_url = reverse('my_app.views.my_view')
>
> > And likewise we could also reference that view using the {% url %} tag
> > in templates.
>
> > What is the recommendation for using reverse() and {% url %} when we
> > migrate to class-based views? So fat the only solution I have come up
> > with is naming the the URL patterns in urls.py, for example:
>
> > urlpatterns = patterns('',
> > (r'^$', TemplateView.as_view(template_name='main/index.html'), {},
> > 'home'),
> > )
>
> > In the above case, we can now reverse('home') or {% url "home" %} -
> > but is this the only way? If so, one would have to give some careful
> > thought to the names of the URL patterns, so that it was readily
> > obvious what view each named URL actually was. For example, one might
> > end up using names like "myapp.IndexView" - a pseudo-hierarchical
> > naming scheme, to essentially bring us back to the place we were with
> > function-based view names.
>
> > I look forward to people's ideas about this...
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/django-developers?hl=en.
>
> --
> Best regards, Yuri V. Baburov, Skype: yuri.baburov, MSN: bu...@live.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Migrating to class-based views and django.core.urlresolvers.reverse
Hi Daniel
On Tue, Dec 7, 2010 at 6:08 PM, Daniel Swarbrick
wrote:
> Forgetting namespaces or existing named URL patterns for a moment, the
> major difference is that with function-based views, we were giving a
> qualified "module.function" parameter to reverse() or {% url %}.
>
> How can we do that with class-based views, without naming every URL
> pattern? Or is it not possible?
Simple. In your views.py:
my_view_function = MyViewClass.as_view()
You can then use `my_view_function` like every other view, like using
it in an url pattern without providing a name or decorating it.
But I think we are slowly approaching django-user territory here...
Kind regards,
Benjamin
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Migrating to class-based views and django.core.urlresolvers.reverse
On 7 December 2010 18:08, Daniel Swarbrick wrote:
> Forgetting namespaces or existing named URL patterns for a moment, the
> major difference is that with function-based views, we were giving a
> qualified "module.function" parameter to reverse() or {% url %}.
>
> How can we do that with class-based views, without naming every URL
> pattern? Or is it not possible?
A similar question was asked here:
http://groups.google.com/group/django-users/browse_frm/thread/847758c4f554c5b9/dee7ebf13296d1ec
It's not possible without extra work. But if you're already doing
extra work, you can just name the view and be nice to people who will
reuse your application. I currently use "-_"
scheme in my projects.
>
> A side question that's been nagging at me during all this is, will
> class-based views become the norm, even in places where we weren't
> using function-based generic views? I was using direct_to_template()
> in 99% of my views, simply because it was a shortcut for the whole
> render_to_response('my_template.html', my_data_dictionary,
> context_instance=RequestContext(request)) palaver. In most cases I was
> still passing an extra_context, but it was a little bit less
> typing ;-)
Your anwser here is the code that was commited today:
http://code.djangoproject.com/changeset/14850
TemplateResponse replaces direct_to_template as a shortcut. CBVs
aren't meant to replace function-views entriely. They are mainly
targeted at generic views and reusable applications.
>
> Another question (sorry - maybe these should be separate posts), how
> does one go about using the permission_required() decorator with class-
> based views, or something like the following:
>
> @user_passes_test(lambda u: u.is_superuser)
> def my_superview(request):
> ...
> return response
>
> Sorry if I'm jumping the gun a little bit. I realise this is a dev
> version and is still in flux.
This is in the docs:
http://docs.djangoproject.com/en/dev/topics/class-based-views/#decorating-class-based-views
PS. As Benjamin already mentioned, I think we're in django-users land now.
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Migrating to class-based views and django.core.urlresolvers.reverse
That is indeed in the docs, and I have seen that. What eludes me is how to use decorators more complex than login_required() from within urls.py. For example, this works fine: from django.contrib.auth.decorators import user_passes_test from django.utils.decorators import method_decorator from django.views.generic import TemplateView, View class IndexView(TemplateView): template_name = 'index.html' @method_decorator(user_passes_test(lambda u: u.is_superuser)) def dispatch(self, *args, **kwargs): return super(IndexView, self).dispatch(*args, **kwargs) But how would one avoid having to override the dispatch() method on many classes, and put the user_passes_test() decorator in the urls.py definition? Or for that matter, the permission_required() decorator? As a side note, could a mixin be used to setup permission_required, login_required etc, and user-defined class-based views be derived from multiple parent classes? Sorry if this has meandered into django-users land... maybe some advanced CBV examples in the docs? On Dec 7, 6:36 pm, Łukasz Rekucki wrote: > On 7 December 2010 18:08, Daniel Swarbrick wrote: > > Another question (sorry - maybe these should be separate posts), how > > does one go about using the permission_required() decorator with class- > > based views, or something like the following: > > > @user_passes_test(lambda u: u.is_superuser) > > def my_superview(request): > > ... > > return response > > This is in the > docs:http://docs.djangoproject.com/en/dev/topics/class-based-views/#decora... > > PS. As Benjamin already mentioned, I think we're in django-users land now. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Migrating to class-based views and django.core.urlresolvers.reverse
Again this topic is now in django-user land. I do this in views.py if want the decorator on all methods (get|post). myview = login_required(MyView.as_view()) On Dec 7, 2010, at 1:10 PM, Daniel Swarbrick wrote: > That is indeed in the docs, and I have seen that. What eludes me is > how to use decorators more complex than login_required() from within > urls.py. > > For example, this works fine: > > from django.contrib.auth.decorators import user_passes_test > from django.utils.decorators import method_decorator > from django.views.generic import TemplateView, View > > class IndexView(TemplateView): >template_name = 'index.html' > >@method_decorator(user_passes_test(lambda u: u.is_superuser)) >def dispatch(self, *args, **kwargs): >return super(IndexView, self).dispatch(*args, **kwargs) > > But how would one avoid having to override the dispatch() method on > many classes, and put the user_passes_test() decorator in the urls.py > definition? Or for that matter, the permission_required() decorator? > > As a side note, could a mixin be used to setup permission_required, > login_required etc, and user-defined class-based views be derived from > multiple parent classes? > > Sorry if this has meandered into django-users land... maybe some > advanced CBV examples in the docs? > > On Dec 7, 6:36 pm, Łukasz Rekucki wrote: >> On 7 December 2010 18:08, Daniel Swarbrick >> wrote: >>> Another question (sorry - maybe these should be separate posts), how >>> does one go about using the permission_required() decorator with class- >>> based views, or something like the following: >> >>> @user_passes_test(lambda u: u.is_superuser) >>> def my_superview(request): >>>... >>>return response >> >> This is in the >> docs:http://docs.djangoproject.com/en/dev/topics/class-based-views/#decora... >> >> PS. As Benjamin already mentioned, I think we're in django-users land now. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Is their much benefit In using a second hidden salt
So I was having a bit of confusion over the method that django uses to protect passwords. The issues I had was that It seen unsecured to have the salt publicly available in the database since anyone who gets hold of the database would know the salt. After rereading the django book and doing some additional research I discovered that this method was particularly targeted at rainbow tables attacks and is indeed view by many as a better option than a system wide hidden salt. However I'm a bit curious about the significance of adding a second salt to the password before it is hashed and then using the regular per-user salt. Currently my opinion is that their is added benefit since it make dictionary attacks more challenging and possibly almost impossibly if the attacker does not know the hidden salt. Django has a secretKey in the setting file I wondering why this could not have been used as second salt in the authentication system. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
django.contrib.admin and null=True
I haven't been able to find any documentation about this, but would be happy to be pointed in the right direction. When you use null=True in a field, and then use that model in the admin, it will not save NULL to the database, but will instead save an empty string (or attempt to). I think this is broken behaviour: NULL values are semantically different to empty strings, and in certain cases (I think it was IPAddressField, but I will have another look later), it would fail to write to the database. Is there a reason that the admin interface saves what should be a NULL value as an empty string? Do I report this as a bug? Matt. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Is their much benefit In using a second hidden salt
On Tue, Dec 7, 2010 at 2:27 PM, andy wrote: > However I'm a bit curious about the significance of adding a second > salt to the password before it is hashed and then using the regular > per-user salt. Currently my opinion is that their is added benefit > since it make dictionary attacks more challenging and possibly almost > impossibly if the attacker does not know the hidden salt. Django has a > secretKey in the setting file I wondering why this could not have been > used as second salt in the authentication system. The problem with this is that if you ever have to change your secret key (e.g., your settings.py file is compromised), then all passwords will be invalidated. And not in a friendly way, either. With per-user salts, if you need to invalidate a user's password, you can allow them to log in with the old password and then require them to change their password. With a secret key in the salt, if you change the secret key, then the old passwords will no longer work at all. Some users may not mind this, but it would be undesirable for core. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Is their much benefit In using a second hidden salt
I see, I really had not give much though to the points that you make. I guess the secret salt really does create some possible inconvenience and should be feature left up to developers to implement as you say. Thanks for the input. On Dec 7, 6:37 pm, Ian Kelly wrote: > On Tue, Dec 7, 2010 at 2:27 PM, andy wrote: > > However I'm a bit curious about the significance of adding a second > > salt to the password before it is hashed and then using the regular > > per-user salt. Currently my opinion is that their is added benefit > > since it make dictionary attacks more challenging and possibly almost > > impossibly if the attacker does not know the hidden salt. Django has a > > secretKey in the setting file I wondering why this could not have been > > used as second salt in the authentication system. > > The problem with this is that if you ever have to change your secret > key (e.g., your settings.py file is compromised), then all passwords > will be invalidated. And not in a friendly way, either. With > per-user salts, if you need to invalidate a user's password, you can > allow them to log in with the old password and then require them to > change their password. With a secret key in the salt, if you change > the secret key, then the old passwords will no longer work at all. > > Some users may not mind this, but it would be undesirable for core. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: django.contrib.admin and null=True
You might consider reading http://docs.djangoproject.com/en/dev/ref/models/fields/#null. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: django.contrib.admin and null=True
On Tue, Dec 7, 2010 at 4:26 PM, schinckel wrote: > I think this is broken behaviour: NULL values are semantically > different to empty strings, and in certain cases (I think it was > IPAddressField, but I will have another look later), it would fail to > write to the database. > > Is there a reason that the admin interface saves what should be a NULL > value as an empty string? Do I report this as a bug? The issue with null IPAddressFields in the admin when using PostgreSQL is known: http://code.djangoproject.com/ticket/5622 In the more general case, the Django philosophy on NULL vs. the empty string is as explained in the link that nasp posted. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
