Re: Removing url() ?

Hi, On Tuesday, 5 May 2020 21:39:35 UTC+1, James Bennett wrote: > > > There's also no reason why url() in particular should be given special > treatment that other deprecated features or APIs don't get. Some other > old-time bits went far more quickly: render_to_response(), for example, got >

Re: [Feature Request] Having an middleware to be able to force authentication on views by default

Hi, Creating Django settings is often discouraged, so perhaps it would be better to create a subclass of AuthenticationMiddleware instead of adding a setting. Then users would update MIDDLEWARE to enable the new functionality. Cheers, Alasdair On Sunday, 15 March 2020 17:46:48 UTC, Mehmet

Re: [Feature Request] DetailView, DeleteView, UpdateView should not work with only slug and primary key field?

Hi, You can already use any unique field as the slug field, for example: path('product//', views.ProductDetail.as_view()), ProductDetail(DetailView) model = Product slug_field = 'order_id' If you want to use a different name in the URL pattern, then set slug_url_kwarg

Re: Allow usage of widgets in generic class-based views?

This is getting into django-users territory, but I wanted to point out that it's often better to leave out the field instead of using a hidden input. You can then override the form_valid() method, and set the value before the form is saved. class PatientCreate(LoginRequiredMixin,

Re: Spaces between argument separator and argument in template filter generate error

On Friday, 1 June 2018 03:06:01 UTC+1, Collin Anderson wrote: > Maybe it would be worth having a more friendly error message? > > I agree, it would be good to improve the message. I've also seen users confused by the "could not parse the remainder" message when they forget the spaces around

Re: #28788: Add support for Model.clean_

On Thursday, 9 November 2017 16:57:22 UTC, Alasdair Nicol wrote: > > On Thursday, 9 November 2017 16:37:50 UTC, Matthew Pava wrote: > >> I don’t use Field.validators much myself, but it seems that the Form >> clean method also calls Field.validators, so the

Re: #28788: Add support for Model.clean_

On Thursday, 9 November 2017 16:37:50 UTC, Matthew Pava wrote: > I don’t use Field.validators much myself, but it seems that the Form clean > method also calls Field.validators, so the redundancy is already there in > the Form class. For consistency’s sake, I suggest we either add >

Re: RedirectView failing silently on NoReverseMatch is confusing

On Thursday, 19 January 2017 12:17:49 UTC, Grzegorz Tężycki wrote: > > I think, that method get_redirect_url should raise ImproperlyConfigured > error with message "Reverse for '' not found.", or NoReverseMatch > exception not should be catch. > I would prefer to stop catching

Re: Template handling of undefined variables

Hi, On Thursday, 5 January 2017 17:51:39 UTC, Tim Martin wrote: > > > > On Thursday, 5 January 2017 04:15:31 UTC, Carl Meyer wrote: >> >> Hi Tim, >> >> On 01/04/2017 03:39 PM, Tim Martin wrote: >> >> > 1) There are test cases where we have templates that should treat "x >> >is y" as True

Re: Changing {% include %} to strip a trailing newline

Would adding the future include tag to the builtins in the template OPTIONS work? If it did, then you'd only have to make the change to the TEMPLATES setting instead of every template. OPTIONS={ 'builtins': ['django.template.future_include'], # put new include in it's own module

Re: CSRF_COOKIE_HTTPONLY is misleading and not useful

On Monday, 28 November 2016 21:38:14 UTC, Tim Graham wrote: > > Meanwhile, there's a ticket [0] asking to expand the documentation of the > settings.CSRF_COOKIE_HTTPONLY. If this setting doesn't provide any value, > then I figure we should remove the system check that suggests to enable it >

Re: Challenge teaching Django to beginners: urls.py

On Friday, 23 September 2016 07:53:49 UTC+1, Sjoerd Job Postmus wrote: > > > I hope I did not offend you with my post on how the code turned out. That > was not my intention, but if it did offend you: my apologies. > > Don't worry, no offence taken :) Cheers, Alasdair -- You received this

Re: Challenge teaching Django to beginners: urls.py

On Thursday, 22 September 2016 15:59:12 UTC+1, Sjoerd Job Postmus wrote: > > Another part I see is that the high coupling between Django and the URL > resolvers (as mentioned in > http://sjoerdjob.com/post/is-djangos-url-routing-tightly-coupled/ ) > should probably be cleaned up, if it is

Re: Decoupling Permission-Check from Calling the View

On Wednesday, April 27, 2016 at 9:55:57 AM UTC+1, guettli wrote: > > Am Dienstag, 26. April 2016 16:27:32 UTC+2 schrieb Alasdair Nicol: >> >> I haven't needed to explain why permission has been granted, but I have >> had admins asking me why a user is g

Re: Decoupling Permission-Check from Calling the View

I haven't needed to explain why permission has been granted, but I have had admins asking me why a user is getting permission denied for a particular view. To answer that, you would 1. Get the url 2. Resolve that to a view 3. Look up the view in the correct views.py, and check which permissions

Re: Django template 'if ... is' feature design

On Thursday, 7 April 2016 23:21:37 UTC+1, Ryan Hiebert wrote: > > > > On Apr 7, 2016, at 5:13 PM, Stephen Kelly > wrote: > > > * Why is there no 'is not' operator? ie '{% if a is not True %}' > > `is not` is probably logical addition, if somebody wants to put in the > time

Re: deprecate or undocument shorcuts.render_to_response()?

I think that updating the docs to use render instead of render_to_response is an good change. Many of the CSRF problems that I see new users struggling with are solved simply by switching to render. Since passing context_instance to render_to_response is deprecated in 1.8. If I understand

Re: @csrf_protect annoying on django.contrib.auth.views.login

;" Friendly view for settings.CSRF_FAILURE_VIEW. """ return render(request, 'friendly_csrf_failure_template.html', status=403) Then in your settings add CSRF_FAILURE_VIEW = 'path.to.csrf_failure'; Cheers, Alasdair [1]: https://docs.djangoproject.com/en/1.8/ref/

Re: Documenting reporting errors on individual fields in Model.clean (#16986)

aving said that, it's not that much more difficult, only 3 extra lines of code in this case. API consistency is a good argument for documenting the ValidationError(dict) approach in both places. Cheers, Alasdair -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.

Documenting reporting errors on individual fields in Model.clean (#16986)

it is ok to document this API. cheers, Alasdair -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK -- You received this message becau

Re: Proposal: ./manage check to look for models.BooleanField() without default= value.

). Ticket and > patch welcome! > > I've created a ticket for this #20895 and am working on a patch now. cheers, Alasdair Nicol > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop r

Additional example for reverse_lazy documentation

is stating "some common cases", it doesn't have to be exhaustive. I'd like to make a ticket and patch if people think this is a good idea. Regards, Alasdair Nicol [1]: http://stackoverflow.com/questions/6512610/django-url-error-in-template-with-password-change-view/6514169 [