Open Xopabyteh opened 7 months ago
Tohle budeme muset ještě nějak rozepsat, že to má být grid a jaké sloupce do něj dát, popř. jaké filtry k tomu.
Měl by to být úplně smiple grid, říkala, že to co bylo minulý rok bylo v pořádku:
Paní ředitelka chce více variant zoobrazení:
1: Tabulku podle tříd prima - septima, pak seřazeno podle příjmení.
Tabulku podle předmětu, pak seřazeno podle příjmení (tady by se asi hodilo zoobrazit i třídu)
Pak by nejspíš mělo vzniknout i něco, kde budou vidět studenti podle tříd, kde bude vidět postupy registrací studentů - mají splněno/nemají a co chybí.
Měl by to být úplně smiple grid, říkala, že to co bylo minulý rok bylo v pořádku:
- Student
- Jméno předmětu
- Možná třída ( minulý rok tam bylo i zápisové pravidlo, ale to teď nepoužíváme, takže budou nejspíš stačit jen tyhle sloupce. )
Paní ředitelka chce více variant zoobrazení:
1: Tabulku podle tříd prima - septima, pak seřazeno podle příjmení.
- Tabulku podle předmětu, pak seřazeno podle příjmení (tady by se asi hodilo zoobrazit i třídu)
To mi přijde, že splňuje dnešní podoba https://intranet.mensagymnazium.cz/electives/registrations, ne? Stačí to jen zafiltrovat dle ročníku nebo dle předmětu a seřadit grid podle potřeby. Jen tam nemáme to příjmení, to můžeme zkusit nějak z toho jména vydloubat.
Pak by nejspíš mělo vzniknout i něco, kde budou vidět studenti podle tříd, kde bude vidět postupy registrací studentů - mají splněno/nemají a co chybí.
Hmm, to je dost obecné zadání, ale můžeme zkusit něco navrhnout.
Pravda!
Tak už zbývá jenom přehled o postupu registrace u studentů. To co vidí student v HomeIndexMyElectives
, ale nějak kompaktněji, třeba jenom Splněno/Nesplněno & možná výčet toho, co chybí, pokud něco.
@hakenr Potřebuju poradit, nevím jak na to. Chci vyrobit grid a pro něj vyrobit query s filterem, která si načte studenty podle filtru, potom pro všechny spočítá ten jejich progress
a vrátí to jako fragment. Napadají mě 3 cesty.
incomplete
registrace, tak to bude potřeba počítat pro úplně všechny studenty a pak opět filtrovat in-memory. Zase ta aplikace má max 200 uživatelů, ale nedovedu vyhodnotit, jestli je to moc, nebo v pohodě na přenačítání do paměti na každý request.cachovat
(třeba InMemory) postupy těch studentů a invalidovat cache, kdykoliv vznikne/zanikne nová registrace toho studenta. Potom tu query odbavovat celou z cache s tím, že už je to předpočítané, takže samý problém s pamětí, ale rychlejší read.DB
, takže celý ten request bude jenom query dotaz do databáze. Nebo jsem úplně mimo a přehlížím to snadné řešení :D
V podstatě bych šel cestou 1., tj. vytáhnul si z DB jen seznam studentů dle filtru a k nim pak in-process dopočítal (pro každého zvlášť) to splnění pravidel. A podle výsledku případně dořešil filtr, že něco dalšího má vypadnout.
Až kdyby se ukázalo, že to je výkonově nepoužitelný, tak bych tam dodělal nějaké cachování výsledků vyhodnocení splnění požadavků - to se dá doplnit do té service kdykoliv dodatečně. Problém ve skutečnosti není to cachování, ale invalidace cache při změnách.
Dříve
StudentsWithSigningRulesList
- komponenta/stránka zoobrazovala studenty a to, jestli měli splněné všechna zápisová pravidla.I Teď by měla ukazovat stav studentů - jestli mají splěné podmínky.