Code

Opened 4 years ago

Closed 4 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:

Description

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 4 years ago.

Download all attachments as: .zip

Change History (3)

Changed 4 years ago by jasongreen

comment:1 Changed 4 years ago by jasongreen

  • Component changed from Uncategorized to Generic views
  • Needs documentation unset
  • Needs tests set
  • Patch needs improvement unset

comment:2 Changed 4 years ago by russellm

  • Resolution set to wontfix
  • Status changed from new to closed

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.