Opened 14 years ago
Closed 12 years ago
#14684 closed New feature (needsinfo)
RESTful Model View
Reported by: | gdoermann | Owned by: | Łukasz Rekucki |
---|---|---|---|
Component: | Generic views | Version: | 1.3-alpha |
Severity: | Normal | Keywords: | models, views, sprintdec2010 |
Cc: | gdoermann@…, kamedov@…, paradise.qingfeng@…, lrekucki@…, Tom Christie | Triage Stage: | Someday/Maybe |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | yes | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
I love the changes that now allow class views. I am probably a bit late in the discussion, but the problem with how they are currently designed is that in the views/generic/edit.py are not RESTful. You have to have a Create, Update and Delete view for each model. I spent some time writing a ModelView that uses the existing code, but allows for a single model view that takes care of all CRUD. The only drawback is that you must use an "action" hidden field whose name can be specified by the "action_name" variable if you want to delete and your browser does not support the DELETE HTTP verb. This is the current way of handling RESTful applications in non-RESTful browsers (or the best way I have found and read about). It does a safe get on the object so if the pk or slug are not passed in it assumes you are creating a new object (so... this could be changed to use the action key as well, but I just played off of what you were doing in the existing get_object for the ModelFormMixin).
Attached is the generic ModelFormView.
Thanks,
Greg
Attachments (1)
Change History (13)
by , 14 years ago
comment:1 by , 14 years ago
Cc: | added |
---|
comment:2 by , 14 years ago
Cc: | added |
---|
comment:3 by , 14 years ago
milestone: | 1.3 |
---|---|
Triage Stage: | Unreviewed → Design decision needed |
Discussed this with Russell at the django sprint. The idea has merit, but needs way too much discussion to be included at this late stage in the 1.3 featureset. The present implementation of class-based views was intended as a drop-in replacement for the previous views system. This design takes things further.
comment:4 by , 14 years ago
Keywords: | sprintdec2010 added |
---|
comment:5 by , 14 years ago
Needs documentation: | set |
---|---|
Needs tests: | set |
Owner: | changed from | to
Patch needs improvement: | set |
I'm intrested in working on this for 1.4 :)
comment:6 by , 14 years ago
milestone: | → 1.4 |
---|
comment:7 by , 14 years ago
Cc: | added |
---|
comment:8 by , 14 years ago
Cc: | added |
---|
comment:9 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:10 by , 14 years ago
milestone: | 1.4 |
---|
comment:11 by , 13 years ago
Easy pickings: | unset |
---|---|
Triage Stage: | Design decision needed → Someday/Maybe |
UI/UX: | unset |
I don't agree entirely when the reporter says "the problem [...] is that [the views] are not RESTful". In my opinion, being RESTful isn't a goal in itself — it's a good thing only if it helps us build better websites faster.
I've seen excellent programmers, using a popular web framework designed around the REST theory, write incredible hacks to force their features in the REST mold, and more often than not it wasn't worth the complexity. I'm not thrilled by the hack to work around the lack of PUT and DELETE in current browsers (the action_name
parameter) either, but I understand its existence.
That said, having shortcuts for typical RESTful views could be useful, if there's a clear gain compared to the current CBVs — maybe a one-liner in the URLconf to declare all the URLs?
As pointed out in comment 3, we'd need to discuss a detailed proposal on the django-developers mailing list before we can accept this feature.
comment:12 by , 12 years ago
Resolution: | → needsinfo |
---|---|
Status: | new → closed |
models.py that could just be added to the views/generic folder.