#1563 closed enhancement (wontfix)
[patch] generic views should accept `manipulator` parameter
Reported by: | Owned by: | Jacob | |
---|---|---|---|
Component: | Generic views | Version: | magic-removal |
Severity: | normal | Keywords: | manipulator |
Cc: | mir@… | Triage Stage: | Unreviewed |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I'd like to be able to pass a Manipulator object into the generic views. This allows a very nice code pattern:
- the view function handles fetching the required data and doing sanity checks, creates a manipulator and calls the generic view
- the generic view handles all the ugly http and form processing, eventually calling the manipulator
- the manipulator does all the customized field stuff (additional/modified fields)
Sometimes this needs to pass special parameters to the initializer of the manipulator (e.g., a ChangeManipulator
) must prepopulate default values dependent on the some other parameter of the view).
I think this makes a great general pattern. I'm willing to put something up in the wiki if you're interested.
Attachments (2)
Change History (11)
by , 19 years ago
Attachment: | generic-views-manipulator.diff added |
---|
by , 19 years ago
Attachment: | generic-views-manipulator.2.diff added |
---|
comment:1 by , 19 years ago
comment:3 by , 18 years ago
Just another Django user who'd love to see this (seemingly small) change implemented; it would enhance and increase the use of generic views by quite a bit. My use case has a model with a field called modifiedBy, which points to the logged-in user. Currently I have to write a separate view and manipulator to take care of filling in that data, when it's just a slightly modified manipulator that's needed.
comment:4 by , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Because manipulators are going away, I don't think we should do this.
comment:5 by , 18 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
Hmm, are you talking also about _custom_ manipulators, or only automatic manipulators?
This usage is specific for custom manipulators, and I can't imagine you really want to remove custom manipulators.
comment:6 by , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
Reclosing -- see Adrian's words.
comment:7 by , 18 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
I assume that you went over this too fast. I asked a direct question to understand what you are doing:
Hmm, are you talking also about _custom_ manipulators, or only automatic manipulators?
This has not been answered, so I don't understand why you closed the ticket.
I don't want to play ping-pong or be obnoxious. If you really didn't want to answer this question, please state so that I know this has not been by accident.
Michael
comment:8 by , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
Since manipulators won't be used by generic views in the near future, this would mean the proposed manipulator
argument would cause pretty different behavior. I'm marking this wontfix again.
comment:9 by , 18 years ago
Thanks, Jacob.
Please understand that this is really valuable information for me. Now I know that I should simply copy the generic views that I use all the time and just change it, instead of patching it in the django source tree. That's also why it is helpful to see your tickets rejected rather than having your change in limbo, not knowing what will happen, maybe for months.
Removed first two lines which have confused trac