Podsumowywanie prototypu planu zajęć studenta

[latarniakonto]

Plan zajęć oferuje widok na stronie, podsumowujący przedmioty, które znajdują się w planie studenta(Ile ECSTS za poszczególny przedmiot, łączna suma ECTS-ów). Prototyp planu zajęć takiej funkcjonalności nie ma, a przedmioty, które wybieramy na nowy semestr trafiają do planu zajęć z mocnym opóźnieniem. To na etapie konstruowania planu na nowy semestr, gdzie prototyp dość dynamicznie się zmienia, dobrze byłoby mieć jakiś właśnie taki kalkulator, który pozwalałby kontrolować liczbę ECTS-ów w prototypie, a nie liczyć wszystko w pamięci. Otwartą kwestią pozostaje, czy w czasie tworzenia prototypu stary plan nie powinien już się pokazywać, bo np. nie jest potrzebny i pokazywać przedmioty, na które jesteśmy zapisani/chcemy się zapisać według prototypu.

[lgpawel]

Dzień po dyskusji pamiętam z niej już istotnie mniej, ale pojawiły się takie obserwacje:

• Okazuje się, że są aż 4 kategorie przedmiotów / grup do podsumowania: te grupy, do których użytkownik jest zapisany (Z), te grupy, do których czeka w kolejce (K), te grupy, które przypiął sobie w prototypie (P), i te przedmioty, które zaznaczył sobie na liście po prawej (L). Pierwsze trzy są trzymane w bazie danych, ostatnia jest wyklikiwana po stronie klienta – to chyba oznacza, że warto się dobrze zastanowić, jak pobierać informacje do podsumowania.
• Podsumowanie kategorii Z powinno wyglądać jak obecnie pod planem zajęć; w szczególności zawiera ono listę grup (zasadniczo to samo, co w planie / prototypie, tylko w innej formie) oraz punkty ECTS za poszczególne przedmioty. (Pytanie: jak w tej chwili wyświetlają się te punkty, kiedy ktoś jest zapisany tylko na wykład, bo ćwiczenia ma już zaliczone? Trzeba pewnie znaleźć osobę w takiej sytuacji i zalogować się na "jej" konto w wersji dev.)
• W podsumowaniu kategorii K i P w liście grup powinny na pewno znaleźć się grupy explicite do nich należące, ale co z wykładami do ćwiczeń należących do kategorii K? Czy listować wszystkie grupy zajęciowe z przedmiotów kategorii L? To może trochę zaśmiecać rezultat dla przedmiotów z wieloma grupami ćwiczeniowymi.
• Przy podawaniu (i podsumowywaniu) punktów ECTS w kategoriach K, P, L trzeba zadbać, żeby nie podawać kolejny raz punktów policzonych wcześniej odpowiednio w kategoriach Z, K, P (Z, K, P, L to chyba dość naturalna hierarchia ich "ważności", choć można się zastanawiać nad kolejnością P i L). Czy w ogóle warto podawać jakiekolwiek punkty dla kategorii P?
• Jeśli chcemy podawać "grand total" punktów (a chyba chcemy), to co do niej liczyć? Z i K wydają się dość oczywiste, L prawie też (bo, powiedzmy, po to zaznaczamy coś na liście, żeby zobaczyć, jak nam pasuje do planu, żeby rozważyć zapisanie się), z P sprawa jest niejasna. Może w podsumowaniu umieścić checkboksy przy poszczególnych kategoriach (albo przedmiotach?), za pomocą których użytkownik mógł wybrać, co do takiej sumy zaliczyć, a co nie?

[latarniakonto]

Po bliższym przyjrzeniu się sprawie po stronie developerskiej pojawiły się u mnie następujące obserwację co do sposobu implementacji tego problemu:

• Przedmioty (Z, K i P) przechowywane w bazie danych jesteśmy w stanie bardzo łatwo włączyć do podsumowywani planu. Całość zostałaby zamknięta w obrębie backend-u w Python-ie oraz frontend-u w HTML-u.
• Implementacja przedmiotów (L) musi zostać praktycznie w całości wykonana po stronie fronted-u. W systemie zapisów do obsługi dynamicznych zmian na stronie (takich, które nie wymagają odświeżania strony) wykorzystuje się Vue. Przedmioty (L) i (Z, K i P) będą operowały na tym samym znaczniku HTML. Jedna grupa w swoim założeniu jest dynamiczna, a druga nie. Z tego też powodu sposób wykorzystywania przez obie grupy tego jednego znacznika, może istotnie się zmienić w porównaniu do tego, gdybyśmy zaimplementowali tylko jedną grupę.
• Osoba, która zaliczyła tylko ćwiczenia bez wykładu, która podchodzi do egzaminu jeszcze raz będzie miała liczone punkty normalnie tak jakby tych ćwiczeń zaliczonych nie miała. Zaliczenie ćwiczeń nic z punktu widzenia podsumowywania nie zmienia.
• Przemioty (P) zawierają w sobie przedmioty (K).

[lgpawel]

Przemioty (P) zawierają w sobie przedmioty (K).

Czyli że jak się jest gdzieś w kolejce, to to od razu jest przypinane do protokołu? (Czy można taką grupę odpiąć w protokole, i czy to oznacza wypisanie z kolejki?) W każdym razie dla powyższej dyskusji podkreśla to tylko, że tam, gdzie pojawia się P bez K, to implicite oznacza to P \ K. (Zresztą w "hierarchii ważności" na pewno na początku są Z i K, potem prawdopodobnie P i L; w opisie w #1248 jest Z, P, K, L – ale może to nie ma dużego wpływu na Pana podejście, nie wiem.)

[latarniakonto]

Przemioty (P) zawierają w sobie przedmioty (K).

Muszę się jednak z tego wycofać. Po przeniesieniu liczenia sumy do frontedu miałem okazję bliżej się przyjrzeć jak powinny działać przedmioty (P) i (K) na prototypie. W szczególności przedmioty (K) nie są od razu przypinane do prototypu planu. Wcześniej bazowałem na komentarzu klasy Pin po stronie backendu, który teraz po pogłębieniu wiedzy w ogóle mi takiej informacji nie daje.