Optional URL parameters in django.urls.path

[Meiyer]

Hi,

I feel there is a use case that the `path()` function does not address and 
thus requires to switch over to `re_path()` which immediately adds a lot of 
additional and error-prone syntax.

Often there is a need to capture a URL parameter which can be optional into 
the view’s kwargs. In terms of path() syntax, this could be accomplished by 
simply allowing, e.g., . However, I am not sure how to handle 
the forward slash that would usually appear after the parameter, and I 
don’t know how difficult it would be to amend the current implementation to 
support this feature.

By the way, if there was a discussion about this before, I couldn’t find 
it. Please point me to it if there was.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/818f30d8-308b-4860-b861-7c7dde9b7aaan%40googlegroups.com.

Re: Optional URL parameters in django.urls.path

[Carlton Gibson]

One approach is to route two patterns (one with the parameter and one
without) to the same URL. Some duplication but (perhaps) easier to read at
a glance than either an optional `?` operator.

Given that — and the alternative re_path() approach being available —
 unless there was a particularly simple implementation on display I'd
likely be sceptical about an addition here… 🤔

On Mon, 19 Sept 2022 at 14:07, Meiyer  wrote:

> Hi,
>
> I feel there is a use case that the `path()` function does not address and
> thus requires to switch over to `re_path()` which immediately adds a lot of
> additional and error-prone syntax.
>
> Often there is a need to capture a URL parameter which can be optional
> into the view’s kwargs. In terms of path() syntax, this could be
> accomplished by simply allowing, e.g., . However, I am not sure
> how to handle the forward slash that would usually appear after the
> parameter, and I don’t know how difficult it would be to amend the current
> implementation to support this feature.
>
> By the way, if there was a discussion about this before, I couldn’t find
> it. Please point me to it if there was.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/818f30d8-308b-4860-b861-7c7dde9b7aaan%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpyTxa291LBc17H7%3DhpdHy3F_sSj2yPz76ncphMa7Mf4qZQ%40mail.gmail.com.

Re: Optional URL parameters in django.urls.path

[Meiyer]

>
> > One approach is to route two patterns (one with the parameter and one 
> without) to the same URL. Some duplication but (perhaps) easier to read at 
> a glance than either an optional `?` operator.
>

I thought about that, but it won't work if I want both cases to be named 
similarly (via the `name` parameter). It also feels as duplicating the same 
line.

> Given that — and the alternative re_path() approach being available — 
>  unless there was a particularly simple implementation on display I'd 
> likely be sceptical about an addition here… 🤔
>

I did a bit of digging in the Django code and in fact it might be quite 
easy (it is also possible I am missing the elephant). django.urls.resolvers 
defines the syntax for the path parameters on line 245 [1] and converts the 
matches to regular expressions on line 290 [2]. Looks like an addition of 
the '?' to the regex after the closing bracket would do it..?


[1] 
https://github.com/django/django/blob/baf9604ed8fed3e6e7ddfaca2d83c377c81399ae/django/urls/resolvers.py#L245
[2] 
https://github.com/django/django/blob/baf9604ed8fed3e6e7ddfaca2d83c377c81399ae/django/urls/resolvers.py#L290

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9e0828d7-6434-4fd1-b605-8113342fcba9n%40googlegroups.com.

RE: Optional URL parameters in django.urls.path

[Matthew Pava]

I wonder if maybe you should look at the APPEND_SLASH setting.
https://docs.djangoproject.com/en/4.1/ref/settings/#append-slash


From: django-developers@googlegroups.com  
On Behalf Of Meiyer
Sent: Monday, September 19, 2022 8:59 AM
To: Django developers (Contributions to Django itself) 

Subject: Re: Optional URL parameters in django.urls.path

> One approach is to route two patterns (one with the parameter and one 
> without) to the same URL. Some duplication but (perhaps) easier to read at a 
> glance than either an optional `?` operator.

I thought about that, but it won't work if I want both cases to be named 
similarly (via the `name` parameter). It also feels as duplicating the same 
line.

> Given that — and the alternative re_path() approach being available —  unless 
> there was a particularly simple implementation on display I'd likely be 
> sceptical about an addition here… 🤔

I did a bit of digging in the Django code and in fact it might be quite easy 
(it is also possible I am missing the elephant). django.urls.resolvers defines 
the syntax for the path parameters on line 245 [1] and converts the matches to 
regular expressions on line 290 [2]. Looks like an addition of the '?' to the 
regex after the closing bracket would do it..?


[1] 
https://github.com/django/django/blob/baf9604ed8fed3e6e7ddfaca2d83c377c81399ae/django/urls/resolvers.py#L245
[2] 
https://github.com/django/django/blob/baf9604ed8fed3e6e7ddfaca2d83c377c81399ae/django/urls/resolvers.py#L290
--
You received this message because you are subscribed to the Google Groups 
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9e0828d7-6434-4fd1-b605-8113342fcba9n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/204fc422ab5c469b91347ec50068a5a9%40Exchange.ISS.LOCAL.

Feature Request: Customisation of constraint error messages in forms

[David Sanders]

Hi folks,

Please note this is partly an extension of some discussion in PR 16054 asking
whether single-field unique or check constraints should raise field errors
as opposed to non-field errors
.

As part of Django's new constraint validation, constraints now get a
violation_error_message

to declare custom user-friendly error messages. Currently,
UniqueConstraints with a single field can additionally have form-specific
error messages set via forms' error_messages

dictionary (or in model form fields). If it's decided that check
constraints also raise field errors then they will also be specifically
customisable in forms.

I'd like to propose that constraints raising non-field errors to also be
specifically customisable in addition to the general default set in
violation_error_message – To do this validation errors would need the
`code` kwarg set.

One possibility is setting the code based on the *constraint name*.
Single-field unique constraints already set the code "unique"; and this
works for field errors because there's usually only one unique constraint
defined for a field.

Thoughts?

Cheers,
David

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADyZw-7b5JoX1kyQvHPKr9pi_yMSNi3OzsbLtSUOXLC0j7MMvA%40mail.gmail.com.

help needed in #33586

[Bhuvnesh Sharma]

Hey , can anyone help me in issue #33586 
 ?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d7e49815-23a1-413f-8922-986d3d32eb31n%40googlegroups.com.

Re: help needed in #33586

[charettes]

Hello Bhuvnesh,

I tried to provide some guidance on the ticket 
. I know you are 
eager on getting help but please allow for a few non-weekend days before 
elevating your request for support as most of us are volunteers here.

Cheers,
Simon

Le lundi 19 septembre 2022 à 15:10:38 UTC-4, bhuvn...@gmail.com a écrit :

> Hey , can anyone help me in issue #33586 
>  ?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9cbd19ef-6448-4d6a-8fe3-6b4dd3f360een%40googlegroups.com.