Opened 4 weeks ago
Closed 4 weeks ago
#35850 closed New feature (wontfix)
Default success messages for CreateView/UpdateView/DeleteView/...
Reported by: | Willem Van Onsem | Owned by: | |
---|---|---|---|
Component: | Generic views | Version: | dev |
Severity: | Normal | Keywords: | translations, success-message, views |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Hi,
I'm wondering if it would make sense to provide default success messages for the CreatView
/UpdateView
/DeleteView
that will *not* be enabled as long as the SuccessMessageMixin
is not enabled, but are when that is the case.
In order to do that we would have to split the SuccessMessageMixin
to trick the MRO in overriding the message. So that would look like:
class BaseSuccessMessageMixin: success_message = "" class SuccessMessageMixin(BaseSuccessMessageMixin): """ Add a success message on successful form submission. """ def form_valid(self, form): response = super().form_valid(form) success_message = self.get_success_message(form.cleaned_data) if success_message: messages.success(self.request, success_message) return response def get_success_message(self, cleaned_data): return self.success_message % cleaned_data
then we can define a DeleteView
like:
class DeleteView(SingleObjectTemplateResponseMixin, BaseSuccessMessageMixin, BaseDeleteView): success_message = _('The object has been deleted successfully')
This would make a simple message easily translatable: people can just add a custom translation and the other ones are retained.
The BaseSuccessMessageMixin
is necessary to make sure that if someone inherits the SuccessMessageMixin
, it will *not* override the success_message
once again by the empty string.
Change History (1)
comment:1 by , 4 weeks ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Version: | 5.0 → dev |
Hello Willen, thank you for taking the time to create this report.
I feel this feature request is a bit tricky because getting a default message right is non-trivial, and OTOH setting a success message on a specific view is very, very straightforward. Adding to that, the solution proposed adds a complexity that I feel is not worth the minimal gain.
Given the above, I'll close the ticket accordingly, but if you disagree, you can consider starting a new conversation on the Django Forum, where you'll reach a wider audience and likely get extra feedback. More information in the documented guidelines for requesting features.
Have a good weekend!