Django ModelForm sok-sok mezővel

A Django beépített ORM-je egy ManyToMany mezővel rendelkezik, amelyet kiválaszthat. Azt hiszem, az alapértelmezett többválasztó szar, és ezt sok végfelhasználó megerősítette, leírva, hogy a választó hogyan hibázik az adott mezők szerkesztése közben. Itt két dolgot írok le. Először, hogyan lehet az adott mező modult megváltoztatni valami ízletesebbre. Ezután leírok néhány letiltást, amelyekre vigyázni kell, amikor ezt a mezőt használja a ModelForms alkalmazással, különösen a mentés során.

A sok-sok kapcsolatot a legjobb elkerülni, ha egyáltalán lehetséges. Rendetlenek és kényszerítik az összes kódot egy reláció több példányának kezelésére. Az étkezés összetevőinek felsorolását sok az egyben képviselni lehet, hacsak nem akarja újra felhasználni ezeket az összetevőket. Akkor két lehetőséged van; vagy engedélyezi a másolást, vagy használjon sok a sokhoz mezőt. Mivel ezeket az összetevőket meg lehet változtatni, és ezt minden étkezéshez meg kell szaporítani, aminek része, ezért az utóbbi megoldást választottam.

Modellek és űrlapkód

Itt található az étkezés alapvető modellkódja, amely modell.py lényegként is elérhető.

Mindez alapvető modellezési dolgok. Az összetevőknek neve és kapcsolata van az étrendhez és az étkezési preferenciákhoz. Az étkezésnek sok összetevője, neve és menükategóriája lehet. 1

Most nézzük meg az Összetevő hozzáadása/szerkesztése űrlapot. Ez egy többcélú ModelForm, amely form.py lényegként is elérhető.

Minden divatos dolog __init__ -ban történik. Inicializálok egy űrlapot az IngredientForm (brand = brand) segítségével az FoodPreference objektumszűrés beállításához, és módosítom a modulokat CheckBoxSelectMultiple-re. Ez rendesen megjelenik jelölőnégyzetek soraként a hülye multi-select helyett.

Díszes M2M kapcsolatok a ModelFormákkal

A furcsaság akkor kezdődik, amikor megpróbáljuk menteni ezt az űrlapot.

Ez hibát vet fel, mivel az űrlap kifejezetten kizárja a Franchise kapcsolatot. A Standard ForeignKey megoldás az comm = False használata és saját maga meghatározása.

Ez látható hiba nélkül működik, amíg vissza nem tér az adott objektumba, és észreveszi, hogy az M2M kapcsolatok (Diet s és FoodPreference s) egyikét sem mentették el. Miért történik ez?

Egy másik mellékhatása az comm = False használatának akkor mutatkozik meg, amikor modelljének sok-sok kapcsolata van egy másik modellel. Ha a modellje sok-sok-sok relációval rendelkezik, és az űrlap mentésekor megadja az Ez azért van, mert nem lehet sok-sok adatot menteni egy példányhoz, amíg a példány nem létezik az adatbázisban.

Így változtatja meg a kódot.

Vegye figyelembe, hogy a save_m2m meghívásra kerül a régi űrlapobjektumra, nem a mentett modellobjektum.

Ezt hangsúlyosabban meg kell említeni a Django dokumentációjában. Ezt a részletet csak azután találtam meg, hogy átgondoltam, hogyan működik az activ = False.

Csomagolás

Django modelljei és ModelFormjai remekek, de bizonyos szempontból minden bizonnyal korlátozottak. Miután elsajátította az alapokat, enyhe változtatások (mint ez) elvégzése eltarthat egy ideig, amíg rájön. Jó hír, ha egyszer megteszed, akkor könnyűek és többet tudsz meg.

Kezdje összeállítani az egyedi Django mezők, az örökölhető absztrakt modellek és néhány új kütyü listáját, hogy az elülső oldal szebb legyen. Ez később időt takarít meg, és értékes írás-újrafelhasználási mintára kényszeríti.

Ez egy ForeignKey-re változik, amikor alkalom nyílik rá. ↩