Přednášky #87
Loading…
Reference in a new issue
No description provided.
Delete branch "prednasky"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Trochu update aplikace přednášek + přidání Tomových požadavků.
e933c697
cb14e4a91eHaha, v adminu seznamu nezobrazuji Znalosti 🤦
prednasky
5125525238WIP: Přednáškyto PřednáškyUživatelsky approved…
TODO testdata, testy, dořešit zbytek exportů (které smazat, které doplnit o
Znalost
i).Mostly LGTM
@ -77,0 +87,4 @@
#: *(přechod z jména na objekt Osoby nějak kape na tom,
#: že všechna předchozí hlasování zde mají náhodný string…)
#: TODO Změnit to na Osobu*
ucastnik = models.CharField("Účastník", max_length=100)
Hmm, existuje čisté a praktické řešení. To čisté a datazachovávající je mít pro osobu nový FK (s
null=True, blank=False
) a mít stará řešení se string-účastníkem a nová s Osobou.Praktické řešení je se na původní hlasy vykašlat, buď je dropnout úplně, nebo jim nastavit Osobu na NULL a pak sice nepůjde dohledat, kdo hlasoval k čemu, ale aspoň informace o zájmu v každém seznamu přežije. (Myslím, že ta druhá varianta vyžaduje zbytečně moc hackování třeba exportů, takže za to nestojí…)
Also: tu Osobu (s null=True) si IMHO chceme ukládat už teď, ať pak můžeme zmigrovat a nechybí nám data… (původní hlasovátko ještě nevědělo nic o účastnických uživatelích/osobách…)
@ -38,0 +16,4 @@
{% for f, p in formy_a_prednasky %}
<h4>{{p.nazev}} ({{p.org}})</h4>
<p class="textprednasky">{{p.anotace}}</p>
<label>Obor: </label> {{p.obor}}<br>
Navrhuji mít kolem každého bloku hlasování aspoň dummy
<div>
, ať se kdyžtak dají různě popřeskládat (kupř. nějakým flexem na ultraširokém monitoru vedle sebe, idk) a nehrozí někde rozbití CSS. (Případně ať si můžu nahackovat dodatečná CSS :-D)@ -15,3 +15,3 @@
<a href="/prednasky/seznam_prednasek/{{seznam.id}}">Seznam přednášek na soustředění {{seznam.soustredeni.misto}} </a>
{% endif %}
<a href="/prednasky/seznam_prednasek/{{seznam.id}}/export">Export</a>
<a href="/prednasky/seznam_prednasek/{{seznam.id}}/hlasovani.csv">Export</a>
{% url … %}
@ -32,3 +43,1 @@
# id z důvodu duplicitních jmen (přechod z jména na objekt Osoby nějak kape na tom,
# že všechna předchozí hlasování zde mají náhodný string…)
# TODO Změnit to na Osobu
ucastnik = osoba.plne_jmeno() + ' ' + str(osoba.id) # id, kvůli kolizi jmen
Asi OK. Možná si teoreticky můžeme místo účastníků u všeho držet celý objekt s informacemi o hlasování k celému seznamu, ale to za to nestojí, zvlášť pokud budeme mít ambice zmigrovat to celé na Osoby.
@ -58,0 +87,4 @@
prednasky = seznam.prednaska_set.all()
znalosti = seznam.znalost_set.all()
# FIXME Spadnout, pokud nesedí přednáška/znalost s formulářem. (Nějak se mi to nepovedlo.)
# Může se totiž stát, že se mezitím změnily přednášky (nějaká byla přidána/odebrána)
A neumíme v takovém případě dát rozumnou hlášku na frontend? (Jakože, špatná sada přednášek je asi divný okrajový případ a mám trochu chuť seznamu o kterém se aktuálně hlasuje zakázat změny, ale je otázka, jestli nemůže nastat nějaký jiný divný stav…)
A když už nic, tak navrhuji tady aspoň zalogovat stav všech formulářů, ať aspoň nepřijdeme o (špatná) data…
No ono možná více okrajový případ je, že form nebude validní (to se musí někde rozbít předvyplnění, musí se v tom účastník hrabat nebo prohlížeč musí dovolit odkliknout radio buttons…)
@ -63,0 +117,4 @@
{
'form_set_prednasky': form_set_prednasky, 'form_set_znalosti': form_set_znalosti,
'formy_a_prednasky': zip(form_set_prednasky, prednasky),
'formy_a_znalosti': zip(form_set_znalosti, znalosti),
Osobní preference: mít z toho „klasické“ datové typy (pole dvojic), ne
zip
objekty, které se konzumují a nedají se proto cyklit opakovaně. (Až to někdo bude zkoušet, tak je imho velká šance, že mu to bude dělat blbosti a nebude chápat proč…)@ -126,0 +221,4 @@
if h.prednaska.id in prednasky_map:
table[h.ucastnik][prednasky_map[h.prednaska.id]] = h.body
else:
pass # TODO Padat hlasitě?
Aspoň warning, ať přijde e-mail… (A i níž…)
Review dokumentace… Asi vesměs usable, jen místy se generuje divně…
@ -12,0 +12,4 @@
"""
Pomůcka pro :py:class:`prednasky.admin.SeznamAdmin` zobrazující hezky :py:class:`Přednášky <prednasky.models.Prednaska>`
v adminu :py:class:`Seznamu <prednasky.models.Seznam>`.
"""
Nechceš tomu prostě říkat Inline a odkázat dokumentaci Djanga rovnou? Přijde mi, že znalý stejně vidí, že to je Inline a neznalému „Pomůcka zobrazující hezky“ dá zbytečně málo informace.
Navrhuji „Inline pro … zobrazující …“
(i dál)
@ -57,1 +89,4 @@
class SeznamAdmin(VersionAdmin):
""" Admin pro :py:class:`Seznam <prednasky.models.Seznam>` """
Tyhle komentáře mi nepřijdou moc užitečné tbh. (Ale aspoň jsou krátké a asi nemám, co dalšího tam napsat anyway.)
Teda, možná se dá popsat, čím se liší od běžného autogenerovaného Adminu (přidání inlinů), ale to je taky literally dva řádky pod tím…
Přidávají informaci, pro jaký model je to admin. (V kódu se dá napravit ta, že budeme místo
admin.site.register
používat správný dekorátor. Ale v dokumentaci ne…)A ano, všechno ostatní je napsané hned podtím (ať už v kódu, nebo v dokumentaci).
Uh, ale jména těch tříd dost držíme konzistentní a taky velmi jasná (i bez dekorátoru). Ale OK, aspoň to přidává odkaz ig
@ -62,3 +97,4 @@
class PrednaskaAdmin(VersionAdmin):
""" Admin pro :py:class:`Přednášku <prednasky.models.Prednaska> """
>`
@ -100,0 +140,4 @@
"""
Admin pro :py:class:`Znalost <prednasky.models.Znalost>
TODO předělat, aby nedědila z :py:class:`prednasky.admin.PrednaskaAdmin`, ale společné věci byly zvlášť
"""
Za
Znalost>
má být`
, předprednasky.admin.PrednaskaAdmin
má taky být`
.Před PrednskaAdmin je…
@ -7,1 +12,4 @@
#: :py:class:`Hodnocení (Body) <prednasky.models.Hlasovani.Body>` této přednášky
body = forms.ChoiceField(label=False, widget=forms.RadioSelect, choices=Hlasovani.Body.choices, initial=Hlasovani.Body.JEDNO)
#: Množina formulářů (:py:class:`formset <django.forms.formsets.BaseFormSet>` :py:class:`HlasovaniPrednaskaFormů <prednasky.forms.HlasovaniPrednaskaForm>`)
btw, proč to automaticky nalinkovalo
formset
na dokumentaci Djanga 3.2 a ne toho, které používáme (což je určitě aspoň 4)?@ -8,0 +17,4 @@
HlasovaniPrednaskaFormSet = forms.formset_factory(HlasovaniPrednaskaForm, extra=0)
class HlasovaniZnalostiForm(forms.Form):
""" :py:class:`Formulář <django.forms.Form>` pro pro :py:class:`HlasováníOZnalostech <prednasky.models.HlasovaniOZnalostech>` o jedné :py:class:`Znalosti <prednasky.models.Znalost>`
Jsem pro smazání jednoho
pro
☺@ -8,0 +24,4 @@
#: ID :py:class:`Znalosti <prednasky.models.Znalost>`, o které hlasujeme
znalost_id = forms.IntegerField(widget=forms.HiddenInput)
#: :py:class:`Odpověď <prednasky.models.HlasovaniOZnalostech.Odpoved>` na tuto znalost
odpoved = forms.ChoiceField(label=False, widget=forms.RadioSelect, choices=HlasovaniOZnalostech.Odpoved.choices)
Ty jednotlivé fieldy mi přijdou dostatečně samopopisné, ale chápu, proč by bez těch dokumentačních komentářů generovaná dokumentace působila divně. Možná spíš rozepsat u
znalost_id
, proč je hidden a jak je to použité v templatech?A není to jasné z toho, jak funguje
forms.HiddenInput
? (A možná moc nechápu, co je myšleno tím použitím v templatech. Tam se jen vykreslí celý form.)Přijde mi dobré mít v tomhle místě při čtení kódu mít kontext, že template tu Znalost rozepisuje nezávisle, a tím pádem ve formuláři se má vložit neviditelně.
Ale je to spíš stylem „když už tam nějaký text má být, tak ať už tam je spíš tohle“…
@ -27,0 +20,4 @@
class Stav(models.IntegerChoices):
""" Stav seznamu přednášek (NAVRH se používá k hlasování viz :py:func:`daný view <prednasky.views.newPrednaska>`). """
NAVRH = 1, "Návrh"
BUDE = 2, "Bude"
Umíme dokumentovat i přímo jednotlivé možnosti? Přijde mi, že si to tady říká o rozepsání, že
NAVRH
odpovídá před-soustřeďkové představě o tom, jaké přednášky dělat (dá se o nich třeba hlasovat ap.), zatímcoBUDE
odpovídá definitivní představě o tom, co bude/bylo a dá se porovnávat s novými návrhy (třeba aby stejná přednáška nebyla na pěti po sobě jdoucích sousech…)(also: za mě sémanticky View využívá Model, takže odkazovat to, jak funguje Model podle použití ve View je kinda divné…)
@ -27,0 +24,4 @@
id = models.AutoField(primary_key=True)
soustredeni = models.ForeignKey(Soustredeni, null=True, default=None, on_delete=models.PROTECT)
stav = models.IntegerField("Stav", choices=Stav.choices, default=Stav.NAVRH) #: :py:class:`Stav <prednasky.models.Seznam.Stav>` Seznamu
Tady se v dokumentaci nenageneruje nic použitelného :-/
Nageneruje se prokliknutelný odkaz.
@ -60,0 +49,4 @@
id = models.AutoField(primary_key=True)
nazev = models.CharField("Název", max_length=300)
org = models.ForeignKey(Organizator, on_delete=models.PROTECT)
popis = models.TextField("Popis pro orgy", null=True, blank=True, help_text="Neveřejný popis pro ostatní orgy")
Gah, tady se prostě zkombinuje název políčka a
help_text
za sebe, takže to pak v dokumentaci vypadá divně (a hlavně nic neříkajícně).A nějaký nápad, jak to vyřešit?
@ -81,0 +117,4 @@
Reprezentuje hlasování jednoho účastníka
o jedné :py:class:`Znalosti <prednasky.models.Znalost>`
v jednom :py:class:`Seznamu <prednasky.models.Seznam>` (účastníkův pohled se totiž mezi sousy změnit)
"""
Asi se hodí napsat, že je to vlastně v podstatě přednáška, akorát s jinými odpověďmi v hlasování a jen o Znalostech získáváme feedback, nic dalšího nezkoumáme (a nevím, jaké další rozdíly jsou…)
@ -75,0 +136,4 @@
"""
Náhled na to, kolik má která přednáška v :py:class:`Seznamu <prednasky.models.Seznam>` :py:class:`hlasů <prednasky.models.Hlasovani.Body>`.
(Je otázka, zda tento View vůbec chceme. Pokud ano, hodilo by se do něj přidat i znalosti.)
"""
To je ten View, o kterém víme, že vlastně vůbec Seznamy neřeší? Tak ten buď smažme, nebo to aspoň zdokumentujme jako známý bug…
strany
obsahují pouze stránky, kde jsou korektury 7da38fbc8aNoooo, asi to lepší nebude… Ideálně někam poznamenat moje výtky k dokumentaci, ale jinak asi mergenout…