Opened 7 years ago

Closed 7 years ago

#12652 closed (wontfix)

create_update should support extra data to be intial and bind on form

Reported by: jasongreen Owned by: nobody
Component: Generic views Version: 1.1
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: UI/UX:


i have write some code to resolve this problem.

  1. sometimes we need initilize the form by querystring when we create an object. e.g. /student/create/?school=2 , is it?
    • initilize by request.GET
  2. sometimes we need initialze the form by sepecified data not contains in request.GET
    • add an initial parameter in create_object,e.g. create(...initial={'owner':request.user,'somthing':something_runtime})
  3. sometimes we need to force to update some field with specified data that not contained in request.POST. or something must be set at server side.
    • add an force_data parameter in create_object and update_object. e.g. create(...force_data=('ip_addr':request.METAREMOTE_ADDR?)
  4. additional change. because of browser cache the form values for each name, if the name is 'name' or some name else appears offen, the browser tip is verbosely. so i think add a prefix to form is good.
    • add prefix for form.

Attachments (1)

create_update.diff (4.3 KB) - added by jasongreen 7 years ago.

Download all attachments as: .zip

Change History (3)

Changed 7 years ago by jasongreen

Attachment: create_update.diff added

comment:1 Changed 7 years ago by jasongreen

Component: UncategorizedGeneric views
Needs documentation: unset
Needs tests: set
Patch needs improvement: unset

comment:2 Changed 7 years ago by Russell Keith-Magee

Resolution: wontfix
Status: newclosed

I'm going to close this wontfix in favour of #6735. Class-based generic views will either have the functionality described here, or will be able to be extended to add this functionality.

Also, as a procedural note, I almost closed this ticket "invalid". Please keep to 1 issue per ticket. In this case, points 1 and 2 are clearly good ideas; 3 and 4 are at the very least debatable. Having all 4 ideas on a single ticket makes it difficult to manage the subproblems.

Note: See TracTickets for help on using tickets.
Back to Top