QST:n attribuutit json-attribuutin alla eivät ole tuettuja

TIM-JYU / TIM

TIM (The Interactive Material) is an open-source cloud-based platform for creating interactive learning documents.

https://tim.education/view/about/en-US

MIT License

13 stars 4 forks source link

QST:n attribuutit json-attribuutin alla eivät ole tuettuja #3610

Open sijualle opened 4 months ago

sijualle commented 4 months ago

https://tim.jyu.fi/view/users/sijualle/kokeiluja/qsthistogrammi Tuossa sijuallen kolmas vastaus (18.2 13:14) tuli eri formaatissa kuin muut. Normaalisti nuo vastaukset tulee yhtenä taulukkona, joissa jokainen rivi on yhden tai nollan alkion taulukko, esim [["1"],[],["2"]]. Nyt tuossa tuli jostain syystä yksi yhden alkion taulukko [["4"]], vaikka edellinen vastaus nro 2 tuli oikeassa formaatissa [["4"],[],[]...].

Mutuna veikkaisin liittyvän jotenkin siihen että tuossa kaikki attribuutit annetaan yhdessä json-attribuutissa eikä erikseen

sijualle commented 4 months ago

Testailin lisää, tuosta json-attribuutista se johtuu, tuo taitaa olla joku mcq:n legacymuoto. Hetken koitin tehdä qst:ssä parsintaa tuolle, mutta siinä ei ollutkaan järkeä, sillä kaikki pluginien .known-kohdat (esim answerLimit ja deadline) pitäisi sitten myös muualla timissä paikata purkalla. Ehkä parempi vain jollain skriptillä käydä läpi kaikki qst:t (joku 1700 kpl) joissa on json-attribuutti, ja nostaa sen aliattribuutit pluginin pääattribuuteiksi

vesal commented 4 months ago

Onkos tuossa siis ongelmaa jos kuitenkin tuokin vastaus on yksikäsitteinen, eli useasta rivistä vain ekaan vastattu? Tuon vaan joutuu ottamaan huomioon käsittelyissä niin, että jos alkiot loppuvat, loput ovat loogisesti tyhjiä. Yritin tuonne sun sivulle tehdä toisen jsonilla ja toisen ilman, mutta en saanut erilaisia vastauksia. Jossakin mielessä jopa tuo "katkaistu" versio olisi tilaa säästävämpi. Sitten on sellainen pointti että ainakin itse joskus saatan lisätä kyselyn alkamisen jälkeen uusia vaihtoehtoja loppuun, jolloin kannassa joka tapauksessa olisi vastauksia joissa on eri mittainen taulukko. Eli käsittelevässä koodissa siihen olisi syytä muutenkin varautua. Mites vastaukset ovat "sotketussa" muodossa. Onko vastaus silti aina "oikeassa" järjestyksessä.

En muista tuon json historiaa. Olisko se jopa niinpäin, että ensin oli tuo json muoto ja sitten tuli tulo "flat"-muoto.

sijualle commented 4 months ago

Tuo että formaatti pienenee ei välttämättä ole ongelma, mutta se syy siihen miksi noin käy on oikea ongelma. Jos antaa attribuutit json-attribuutin alla niin aina vastauksen tallentamisen jälkeen tuo qst:n fronttikoodi käytännössä hajoaa koska palvelimelta ei tule sitä mitä pitäisi

Kaikki vastauksen näyttämiset, answerLimitien tarkistukset yms on täysin rikki jos antaa qst:n markupin tuolla vanhalla json-attribuutilla. Ja sen sijaan että tuota paikkailisi erikoiskäsittelyillä olisi parempi vain vaihtaa kaikki nykyiset tehtävät jollain skriptillä uuteen muotoon.

Vaihdan tuota otsikkoa kuvaamammaksi