Opened 8 years ago
Closed 8 years ago
#27273 closed Cleanup/optimization (fixed)
Make usage of construct_change_message easier outside of admin
Reported by: | Alexey Rogachev | Owned by: | nobody |
---|---|---|---|
Component: | contrib.admin | Version: | dev |
Severity: | Normal | Keywords: | admin, form |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
I use django-reversion library in one of my projects. In admin it uses ModelAdmin
's change message generated by construct_change_message
method as revision comment. Besides admin I also need to generate same change message on object creation / editing on frontend part of a site.
Using construct_change_message
outside of admin is now possible like that:
from django.contrib.admin import AdminSite from enterprises.admin import EnterpriseAdmin comment = EnterpriseAdmin(enterprise, AdminSite).construct_change_message(request, form, formsets, create)
enterprise
is either created or edited model, create
- boolean variable (True
when create and False
otherwise).
I think it's not clean to refer to admin from frontend like that.
As a suggestion, we can move the method outside of a class. It does not use self
also.
Another option is to make this method static, but this will just reduce a bit of code, and problem of referring from frontend to admin will still present.
I understand that this was probably initially designed for admin only, but still sometimes we need to use it on frontend, so why not reuse existing functionality to keep code DRY.
Change History (6)
comment:1 by , 8 years ago
Description: | modified (diff) |
---|
comment:2 by , 8 years ago
Description: | modified (diff) |
---|
comment:3 by , 8 years ago
Type: | Uncategorized → Cleanup/optimization |
---|
comment:4 by , 8 years ago
Has patch: | set |
---|---|
Triage Stage: | Unreviewed → Accepted |
I guess adding a utility function might be fine. PR
I guess making it a static method could be fine (except that it's backwards-incompatible for
ModelAdmin
subclasses), but I'm not sure if reorganizing the code and making it a function (at the expense of readability) is worthwhile. Also, that would remove the ability for subclasses to customize the method (absent the introduction of another helper function).