Navigare contextuală
# 5986 închis Funcție nouă (fix)
| Michał Sałaban | Detinut de:nimeni |
| Formulare | Versiune:maestru |
| Normal | Cuvinte cheie:ordinea câmpului greutatea formează noi forme |
| marc.garcia@…, matti.haavikko@…, sime, Simon Charette, Loic Bistuer, tanar | Etapa de triaj:Gata pentru checkin |
| da | Necesită documentație:Nu |
| Nu | Patch-ul are nevoie de îmbunătățiri:Nu |
| Nu | UI/UX:Nu |
Descriere
Luați în considerare acest exemplu:
UserProfileForm poate moșteni toate bunurile UserForm: câmpuri și validatori. Dar ordinea câmpului poate părea cam dezordonată atunci:
Ar fi frumos să aveți e-mailuri grupate cu jabber_id, prenume și prenume cu nume de utilizator etc. Desigur, este posibil să o faceți folosind un șablon personalizat, dar încalcă principiul DRY și face ca metodele _ * () să fie inutile.
Patch-ul atașat permite specificarea unei comenzi de câmp personalizate într-un formular, chiar și cu câmpuri moștenite.
Fiecare câmp poate avea un parametru de greutate suplimentar cu valoarea implicită de 0. Toate câmpurile sunt sortate în ordine crescătoare de greutate.
Formele de exemplu personalizate cu parametri de greutate:
Atașamente (4)
Acum 13 ani. Patch corect, inclusiv teste de regresie django-fields-order.3.patch (5,6 KB) - adăugat de Patryk Zawadzki
Acum 13 ani. A fost adăugat suport pentru form_for_model
Descărcați toate atașamentele ca: .zip
Istoricul modificărilor (45)
Schimbat acum 13 ani de Michał Sałaban
Patch-ul adăugând parametrul de greutate la newforms.Field
comentariu: 1 Schimbat acum 13 ani de patrys @ ...
Ar putea fi mai util să o reimplementați ca meta-proprietate care conține lista dorită de nume de câmpuri (modul în care definiți coloanele de afișat pentru interfața de administrare). În acest fel, fiecare formular poate avea propria sa listă independentă acolo și puteți încerca de fapt să extindeți două forme simultan, menținând în același timp rezultatul corect și previzibil.
comentariu: 2 Schimbat acum 13 ani de Michał Sałaban
Deci, iată-l, cu lista Form.Meta.fields_order.
Schimbat acum 13 ani de Michał Sałaban
A doua abordare, cu Form.Meta.fields_order
Schimbat acum 13 ani de Patryk Zawadzki
Patch corect, inclusiv teste de regresie
comentariu: 3 Modificat acum 13 ani de Patryk Zawadzki
| Ordinea câmpului personalizat în formele noi → [PATCH] Ordinea câmpului personalizat în formele noi |
Schimbat acum 13 ani de Patryk Zawadzki
A fost adăugat suport pentru form_for_model
comentariu: 4 Modificat acum 13 ani de Patryk Zawadzki
comentariu: 5 urmăriri: 6 7 Modificat acum 13 ani de jkocherhans
Îmi pare rău că sunt direct, dar nu aș putea fi mai împotrivă acestei schimbări sau mai bine zis a sintaxei greutate = X. Lucrez la o nouă clasă numită ModelForm chiar acum (căutați django-dev pentru firul relevant) care ar trebui să permită ceva similar cu atributul fields_order de mai sus. Doar se numește câmpuri și va restricționa de fapt și câmpurile care apar în formular.
comentariu: 6 ca răspuns la: 5 Modificat acum 13 ani de Patryk Zawadzki
Îmi pare rău că sunt direct, dar nu aș putea fi mai împotrivă acestei schimbări sau mai bine zis a sintaxei greutate = X. Lucrez la o nouă clasă numită ModelForm chiar acum (căutați django-dev pentru firul relevant) care ar trebui să permită ceva similar cu atributul fields_order de mai sus. Doar se numește câmpuri și va restricționa de fapt și câmpurile care apar în formular.
Acest lucru are puțin sau nimic de-a face cu sintaxa form_for_ *. Aceasta adaugă capacitatea de ordonare pentru toate subclasele Form, deoarece funcționează numai în interiorul metaclasei. Dacă clasa dvs. ModelForm sau orice altă clasă extinde Formular, atunci câștigă această caracteristică gratuit.
Singurul bit relevant ar fi eliminarea micului bloc de cod, inclusiv comentariul despre form_for_ * odată ce aceste funcții mor.
Cred că patch-ul este încă adecvat pentru a comite și adaugă un test de regresie frumos, astfel încât să puteți fi siguri că lucrurile funcționează așa cum au făcut și vor continua să facă acest lucru.
comentariu: 7 ca răspuns la: 5 Modificat acum 13 ani de Michał Sałaban
Îmi pare rău că sunt direct, dar nu aș putea fi mai mult împotriva acestei schimbări, sau mai bine zis a sintaxei greutate = X. Lucrez la o nouă clasă numită ModelForm chiar acum (căutați django-dev pentru firul relevant) care ar trebui să permită ceva similar cu atributul fields_order de mai sus. Doar se numește câmpuri și va restricționa de fapt și câmpurile care apar în formular.
Sintaxa greutății este învechită. Vă rugăm să consultați ultimul patch și exemplu.
Am găsit discuția despre ModelForms, dar nu văd dacă se ocupă de ordinea câmpurilor. Și cum pot fi utilizate pentru a crea formulare care nu sunt bazate pe modele?
Oricum, nu văd nicio problemă în coexistența ModelForms și Meta.fields_order de mai sus.
comentariu: 8 Schimbat acum 13 ani de bear330
Acest lucru ar putea fi inutil, dar modul meu de a comanda câmpurile este:
Oricum, clasa Meta cu fields_order ar trebui să fie o modalitate mai bună, deoarece coordonarea cu convenția django.
Am postat aici doar ca referință.:)
comentariu: 9 Modificat acum 13 ani de Pete Crosier
| a stabilit |
| [PATCH] Ordinea câmpului personalizat în formele noi → Ordinea câmpului personalizat în formele noi |
comentariu: 10 Schimbat acum 13 ani de MichaelBishop
Trebuie luată o decizie dacă adăugarea unui ordin de câmp personalizat este un „lucru bun”. IMHO, aceasta nu pare a fi o caracteristică critică. Oricum ar fi nevoie de o decizie de proiectare.
comentariu: 11 Modificat acum 13 ani de James Bennett
# 6369 și # 6878 au fost închise ca duplicate.
comentariu: 12 Schimbat acum 13 ani de David Cramer
O putem numi ordonând să rămână cu un nume de variabilă care este deja folosit în loc să creeze mai multe?
Michael, caracteristicile nu trebuie să fie critice pentru a fi dorite:)
comentariu: 13 Modificat acum 13 ani de Simon Blanchard
comentariu: 14 Schimbat acum 12 ani de Marc Garcia
Mai ales pentru că este necesar și pentru ModelForm, unde câmpurile atributului Meta nu au putut fi utilizate pentru sortare. Fără un parametru de comandă, nu este ușor să poziționați în locul corect un parametru suplimentar al unui ModelForm.
comentariu: 15 Schimbat acum 12 ani de Michael Radziej
not a bug => not jalon 1.0 beta.
comentariu: 16 Schimbat acum 12 ani de Matti Haavikko
comentariu: 17 Modificat acum 12 ani de GertSteyn
Clasa meta:
fields = ('first_field', 'second_field', 'third_field',)
def init (self, * args, kwargs):
super (FooForm, self). init (* args, kwargs)
self.fields.keyOrder = self.Meta.fields
Patch-ul a fost redus acum la un singur liner:
"self.fields.keyOrder = self.Meta.fields"
comentariu: 18 Modificat acum 12 ani de sime
comentariu: 19 Schimbat acum 12 ani de Grigoriy Petukhov
Patch-ul a fost acum redus la un singur liner: "self.fields.keyOrder = self.Meta.fields"
Cred că nu este corect. În acest caz, vor fi afișate numai acele câmpuri descrise în Meta.fields.
Câmpurile personalizate care au fost adăugate în init sau în clasă vor fi trunchiate.
comentariu: 20 Modificat acum 12 ani de miracle2k
comentariu: 21 Schimbat acum 12 ani de Alex Gaynor
Închiderea ca valoare a # 8164, deoarece are API-ul mai bun.
comentariu: 22 Modificat acum 12 ani de către (none)
Etapa post-1.0 ștearsă
comentariu: 23 Modificat acum 6 ani de Markus Bertheau
| dezactivat |
| duplicat |
| → Normal |
| închis → nou |
| → Necategorizat |
| dezactivat |
Aceasta nu este o înșelăciune de # 8164, deoarece asta vorbește doar despre și implementează ordonarea câmpului pentru ModelForms.
comentariu: 24 Schimbat acum 6 ani de Collin Anderson
| Ordinea câmpului personalizat în formulare noi → Ordinea câmpului formularului personalizat |
| Este necesară o decizie de proiectare → Nerevizualizat |
| Necategorizat → Funcție nouă |
Eu nu am încercat asta, dar ar funcționa o sintaxă ca aceasta?
comentariu: 25 Modificat acum 6 ani de Tim Graham
| dezactivat |
| dezactivat |
| Comandă de câmpuri de formulare personalizate → Mod simplu de personalizare a ordonării câmpurilor de pe formularele care utilizează moștenirea |
| Nerevizualizat → Acceptat |
Pre-Django 1.7, următoarele au funcționat, dar s-au bazat pe detalii de implementare interne (că self.fields a fost SortedDict; acum este OrderedDict):
Adăugarea unui API oficial pentru simplificarea comenzii pe formularele care folosesc moștenirea pare rezonabilă. Nu sunt sigur dacă recomandarea base_fields este cea mai bună abordare, deoarece nu este API public de acum.
comentariu: 26 Modificat acum 6 ani de Tim Graham
# 23936 a fost un duplicat și a inclus o cerere de extragere.
comentariu: 27 de urmăriri: 28 29 Modificat acum 6 ani de Loic Bistuer
Nu pot spune că sunt convins cu acest bilet, câmpurile de comandă IMO aparțin șabloanelor.
comentariu: 28 ca răspuns la: 27 Modificat acum 6 ani de Alasdair Nicol
Nu pot spune că sunt convins cu acest bilet, câmpurile de comandă IMO aparțin șabloanelor.
Am folosit self.field.keyOrder în versiunile anterioare ale Django și aș găsi util un API oficial. Dacă redați formularul în șablon cu> sau>, atunci este mult mai ușor să schimbați ordinea câmpului în formular decât șablonul.
PasswordChangeForm din aplicația contrib.auth modifică ordinea câmpurilor modificând câmpurile_bază. Cred că este mult mai bine să o schimbi acolo decât să le spui utilizatorilor să plaseze „parola veche” înainte de „parolă nouă” în șablonul lor. Ar fi și mai bine dacă am folosi un API public pentru a schimba ordinea câmpului.
comentariu: 29 ca răspuns la: 27 Modificat acum 6 ani de Simon Charette
Nu pot spune că sunt convins cu acest bilet, câmpurile de comandă IMO aparțin șabloanelor.
Problema este că ordinea câmpului afectează și ordinea apelurilor clean_.
comentariu: 30 de urmărire: 31 Modificat acum 6 ani de Carl Meyer
Hmm, întotdeauna am crezut că nu mă bazez pe comanda apelurilor clean_; o metodă clean_ ar trebui să se ocupe doar de câmpul său și nimic altceva, dacă trebuie să validați mai multe câmpuri, ar trebui să fie făcută în curat .
Cred că, în majoritatea cazurilor, formularele sunt redate mai bine în mod explicit în șablon și de aceea aparține ordonarea câmpului. Dar există cazuri de utilizare (aplicații mai generice, cum ar fi administratorul), în care acest lucru nu este practic. Faptul că reordonăm câmpurile de formă în Django este un argument destul de puternic că ar trebui să existe un API public pentru acesta.
comentariu: 31 ca răspuns la: 30 Modificat acum 6 ani de Loic Bistuer
Hmm, întotdeauna am crezut că nu mă bazez pe comanda apelurilor clean_; o metodă clean_ ar trebui să se ocupe doar de câmpul său și nimic altceva, dacă trebuie să validați mai multe câmpuri, ar trebui să se facă în curat .
+1, mai ales acum că add_error () face foarte ușor de făcut.
Cred că, în majoritatea cazurilor, formularele sunt redate mai bine în mod explicit în șablon și de aceea aparține ordonarea câmpului. Dar există cazuri de utilizare (aplicații mai generice, cum ar fi administratorul), în care acest lucru nu este practic. Faptul că reordonăm câmpurile de formă în Django este un argument destul de puternic că ar trebui să existe un API public pentru acesta.
Citat din PR privind Form.field_order: "Câmpurile lipsă din listă sunt eliminate". Mă tem că acest lucru adaugă încă un alt mod de excludere a câmpurilor, ModelForm este deja destul de confuz cu ambele câmpuri și excludere (și posibila suprapunere a celor două). Există, de asemenea, interacțiunea cu ModelAdmin care acceptă deja ordonarea câmpurilor prin câmpuri și seturi de câmpuri .
În cele din urmă aș dori să subliniez că API-ul propus nu se joacă bine cu moștenirea. Nu l-am putea folosi în PasswordChangeForm, de exemplu, deoarece ar rupe orice subclasă cu câmpuri suplimentare.
Sortarea self.fields în __init __ () obține oricum același rezultat?
comentariu: 32 Modificat acum 6 ani de tanner
Mi-am revizuit PR-ul pentru a-l face complet compatibil înapoi.
Atributul/argumentul field_order este utilizat pentru a rearanja câmpurile existente.
Dacă o listă a unui câmp existent lipsește în listă, câmpul este atașat câmpurilor în ordinea inițială.
În acest fel, câmpurile noi din subclasă sunt adăugate (ca înainte) dacă subclasa nu suprascrie câmpul_ordine.
Dacă o cheie din field_order se referă la un câmp inexistent, este pur și simplu ignorată.
Această marcă este posibilă eliminarea unui câmp dintr-o subclasă, suprascriindu-l cu None, fără a suprascrie field_order.
Din nou, acest lucru nu va sparge subclasele existente.
Dacă nu definiți Form.field_order sau nu îl setați None, ordinea implicită este păstrată.
Acum există trei moduri de a seta ordinea câmpului:
- Cele mai bune 4 aplicații pentru a-ți pierde grăsimea de pe burtă rapid și ușor
- 10 moduri ușoare de a obține recenzii ale clienților care stimulează vânzările cu amănuntul
- 4 metode ușoare pentru a face ceai sănătos de păpădie și 13 rețete de încercat
- 10 sfaturi ușoare și inteligente de slăbit din întreaga lume The Times of India
- 10 moduri fantastice și ușoare de a pierde în greutate în timp ce faceți treburile casnice