Tehtävätietojen talletus TIMiin #694

Closed dezhidki closed 2 years ago

In GitLab by @Smibu on Jul 29, 2014, 14:04

Vaatimuksia tänne:

Opiskelija voi vastata yksin tai laittaa kavereita mukaan samalla kertaa, jos tekevät ryhmissä.
- Tähän pitäisi speksata, miten kavereita laitetaan ja talletetaanko vastaukset jokaiselle kaverille erikseen vai jotenkin kaikille yhdessä.
- Mitä tapahtuu, jos joku muuttaa vastaustaan jälkikäteen?
- Miten taataan se, ettei laita kavereita vastaajiksi, vaikkeivät ole paikalla. Ehdotus: Tehtävän kohdalla jokainen voisi rekisteröityä TIMiin tai TIMiin voi rekisteröityä useita henkilöitä ja silloin tämän session aikana kaikki vastaukset tallentuvat jokaiselle henkilökohtaisesti (leimalla nämä tekijät). Kun joku menee yksin muuttamaan vastausta, hän "eroaa ryhmästä" ja hänen vastauksestaan syntyy uusi oma versio (mutta selaamisessa opettaja näkee vanhemmankin ryhmässä tehdyn version).
Opiskelija voi ehdottaa pisteitä itselleen.
Opiskelija voi tarkastella omaa tehtävää.
- Näkyy luonnostaan
- Miettimistä siinä, miten rajoitetaan vastauskertojen määrä ja mahdollinen takaraja vastaukselle .
Opettaja saa vastaukset näkyviin helposti
- Oma TIMin "appi", jolla vastauksia selaillaan ja muutellaan tarvittaessa pisteitä.

Tietokannan rakenne tehtävien vastausten ja pisteiden talletuksen osalta

Seuraavassa esimerkissä käyttäjät vesal ja kalle ovat vastanneet tehtävään lumiukko ensin yhdessä, ja myöhemmin vesal on korjannut omaa vastaustaan ja antanut paremmat pisteet itselleen.

Taulu Answers:

aid |      taskId | answercontent | points |      timestamp
  1 | 22.lumiukko |   {choice: 3} |    1.5 | 4.9.2014 15:30
  2 | 22.lumiukko |   {choice: 2} |      3 | 9.9.2014 14:40

answercontentin sisältö voi olla myös tiedostossa, jos vastaus on iso, jolloin sarakkeessa on viite tiedostoon.

Taulu UserAnswers:

aid | uid
  1 | vesal
  1 | kalle
  2 | vesal

Taulu AnswerTags:

aid | tag
  1 |   3
  2 |   2

In GitLab by @Smibu on Jul 29, 2014, 11:08

@villetirronen Kysymys tallentuu kuten muutkin dokumentin kappaleet eli kutsutaan /postParagraph, joka ottaa vastaan dokumentin id:n, kappaleen indeksin, jota muokattiin ja kappaleen uuden sisällön. Eli JavaScriptilla voi tallentaa.

In GitLab by @Smibu on Jul 29, 2014, 11:11

@mikalehtinen Olisiko fiksua, että näitä plugareita varten tekisi vaikka timin skriptien mukaan angularin $servicen, joka hoitaisi talletuksen. Plugarien tekijöiden ei tarttisi miettiä noita requesteja ja jos rajapinta muuttuu, niin plugareita ei tarttisi tehdä kaikkia uudestaan. – Ville Tirronen

In GitLab by @Smibu on Jul 29, 2014, 11:12

@villetirronen Pluginien ja timin välisessä keskustelussa pitää tosiaan jotenkin tunnistaa käyttäjä. Jos plugin kutsuu timiä(?), niin pluginille pitää luultavasti kertoa käyttäjän sessiotunniste. Tietojen haku tapahtunee /getAnswer -routella, mutta sitäkin täytyy tarkemmin miettiä.

In GitLab by @Smibu on Jul 29, 2014, 23:38

Mun ajatus, ks: https://trello.com/c/14dGdk5x/23-csrun-plugin

Tämä lähinnä csRun-pluginin kannalta. Jos csRun on käynistetty iFrameen, ei sillä ole mitään kontaktia TIMiin vastausken tallentamsieksi. Siksi

kun csRun-pluginilta pyydetään sen html (tai iframen sisältö), yhtenä POST-parametrina menee käyttäjän edellinen vastaus tähän tehtävään.
toisena POST-parametrina tulee osoite, johon vastaus lähetetään modulin haluamassa muodossa. Osoite voidaan antaa vaikka: ticket=https://tim-beta.it.jyu.fi/answer/?ticket=0123-ABCD-...2344 ja kun tuohon osoitteeseen lähetään ja perään liitetään käyttäjän vastaus ja pisteet (userAnwer= userPoint=) siinä muodossa kuin moduli sen haluaa tallentaa. Esim. cs-moduli voisi lähettää talletettavan datan muodossa jossa on käyttäjän kirjoittama koodi ja sitten jotenkin erotettuna koodista syntyneen kuvan URL. Näin seuraavalla kerralla kun moduli käynnistyy tälle käyttäjälle tästä tehtävästä, niin saadaan takaisin tuo sama koodi ja URL, jolloin molemmat voidaan näyttää modulissa modulin haluamalla tavalla (koodi textareaan ja kuva sen alle). Samalla voi tulla uusi ticket-arvo muutoksen tallentamiseksi. Tällä tavalla jokainen eri käyttäjän vastaus samaan tehtävään tallentuu käyttäjän "Kommentin" eri versioksi. Tuon tiketti-numeron perusteella TIM tietää kenelle ja mihin tehtävään liittyen vastaus talletetaan. Modulin ominaisuuksiin voi m yös kuulua se, että moduli tallettaa vastauksen itse user/taskID-tiedon perusteella (antaako tämä mahdollisuuden modulin väärinkäyttöön?)
Näin periaatteessa TIMin kannalta riittää että on olemassa erilaisia kommentti-tyyppejä
- tehtävän vastaus
- tavallainen yksityinen kommentti
- kommentti, jonka kaikki ryhmäläiset näkevät
- yksityinen kommentti, jonka myös opettaja näkee
- on ollut tämän kappaleen kohdalla
- on kuitannut kappaleen luetuksi
- on kuitannut kappaleen ymmärretyksi Muuten kaikki kommentit talletetaan samalla tavalla, niitä näytettäessä otetaan huomioon tuo kommentin "tyyppi". Tehtävien vastauksia ei näytetä muiden tapaan, vaan ne näytetään modulin toimesta. – Vesa Lappalainen

In GitLab by @Smibu on Jul 30, 2014, 24:54

Tähtävien vastausten yhteyteen pitäisi voida tallentaa myös tehtävästä saadut pisteet. Pisteet voi tulla

automaattisesti (esim. monivalinnat tai jos ohjelman tehtävä on jotakin yksikäsitteistä tulostusta. Ohjelmissa miinuksia
voi tulla (versiossa 10.2) liioista if-lauseista tms.)
opiskelijan itsearviona (kuten nykyisin NettiDemoWWW)
opettajan antamana (tai opiskelijan itsearviota muuttamalla)
toisen opiskelijan antamana

Pistemäärä voisi varmaan olla taas yhdentyyppinen kommentti, jolloin jos kommenttien historia tallentuu, niin myös pisteiden osalta tallentuu kuka on antunut, milloin ja vielä jos pisteitä muutettaessa (opettaja/toinen opiskelija) joutuisi antamaan kommentin siitä, miksi on muuttanut pisteitä. – Vesa Lappalainen

In GitLab by @Smibu on Jul 30, 2014, 09:22

Eli TIMiin pitäisi luultavasti tehtäväkohtaisesti (vai jollain muulla tarkkuudella) tallettaa tieto siitä, kuka voi antaa pisteet tehtävään. Ettei itselleen voi antaa 999p (paitsi tapauksessa 2 toki) jne.

Kommenteista ei (toistaiseksi) tallennu aikaleimaa, mutta se on tosiaan helppo lisäys.

In GitLab by @Smibu on Jul 30, 2014, 10:17

Tämä tehtävien pisteytys/arvostelu jne. on minusta aika suuri kokonaisuus. Vrt. Tämähän on sama kuin demo-www ja sitäkin on tehty vuosia.

Voisiko tämä olla plugin? – Ville Tirronen

In GitLab by @Smibu on Jul 30, 2014, 22:39

automaatteineen ehkä kohtuullinen. mutta minusta ei plugin, koska se liittyy mahdollisesti jokaiseen pluginiin. esim monovalinta plugin palauttaisi käyttäjän vastauksen talletuksen yhteydessä opiskelijan tehtävästä ansaitsemat pisteet.

demowww ei tee pisteillä juuri mitään, ne vaan nostetaan sielä korppiin.

alottaisin sillä että plugin voi palauttaa pisteet ja sitten toisena vaihtoehtona opiskelijan itse antamat pisteet (esim CsRun) – Vesa Lappalainen

In GitLab by @Smibu on Jul 31, 2014, 13:12

@vesal Eikö pluginia voisi ajatella palveluna, jota muutkin pluginit voisivat käyttää? – Ville Tirronen

In GitLab by @Smibu on Jul 31, 2014, 13:24

Sellainen se vähän onkin, mutta se on selkeä osa TIMiä (ei välttämättä tuossa dokumentin koodissa???, mutta pyörii samassa kontissa) TIM antaa tehtävää näyttäessään osoitteen ja tiketin, jolla plugin saa tallettaa ko. käyttäjän vastauksen (ks alempana). Tällöin pluginin (ei välttämättä, mutta saa) tarvitse tietää käyttäjän tunnuksia tai tehtävän numeroa.

Plugin voi pyytää nuo käyttäjä/tehtäväId tiedot, ks: https://trello.com/c/14dGdk5x/23-csrun-plugin – Vesa Lappalainen

In GitLab by @Smibu on Jul 31, 2014, 13:26

@vesal Miten plugineja voi testata ilman, että joutuu asentamaan työkoneelleen koko TIM:n? Miksei TIM voisi koostua useammasta, erikseen käytettävästä palasta? – Ville Tirronen

In GitLab by @Smibu on Jul 31, 2014, 13:35

antaa pluginille tuossa ticket-osoitteessa lokaalin koneen tunnuksen ja minkä tahansa ticket-arvon. Jos pligin toimii, se lähettää silloin vastauksen ja pisteet (jos lähettää pisteitä) sille lokaalille koneelle. Testissähän niitä ei tarvitse tallettaa mihinkään, riittää jotenkin näyttää. Mutta jos haluaa tallettaa, niin tallettaa vaikka tuota ticket arvoa vastaavaan tiedostoon tms Periaatteessa ticket arvo testeissä voi olla vaikka muotoa: vesal.t1 jolloin pluginin vastaus vesal-käyttäjälle, tehtävään 1 tallettuis testikoneessa tiedostoon vesal.t. – Vesa Lappalainen

In GitLab by @Smibu on Jul 31, 2014, 13:36

@vesal En näe, että miten tuo voisi paljastaa mitenkään, että toimiiko plugari timin kanssa yhteen. – Ville Tirronen

In GitLab by @Smibu on Jul 31, 2014, 13:49

TIM toteuttaa tietyn rajapinnan (eli on osoite johon saa lähettää vastauksia). Rajapinnan parametrit ovat ticket=, userAnswer=, userPoints=. Jos itse tehdään vastaava MOCK-rajapinta, niin siltä osin toimii. Tuohon täytyy luottaa että kun plugin lähettää TIMin antamaan osoitteeseen dataa tiedoilla, niin TIM osaa nuo tallettaa. Ja kun pluginin seuraavassa käynistyksessä TIM toimittaa vastaavat tiedot pluginille, niin siihen pitää voida luottaa, että ne ovat osa pluginille tulevaa requestia.

TIM vastaa tuohon talletus(yritykseen) joko OK tai sitten mahdollisev virheilmoituksen. Virhe voi tulle mm. siitä, että ticket on vanhentunut (esim. käyttäjä on avannut saman tehtävän uuteen selaimeen josta on tullut uudempi ticket-arvo tietojen talletukseen) – Vesa Lappalainen

In GitLab by @Smibu on Jul 31, 2014, 14:14

@vesal Ok. Entä se käyttötapaus, jossa pluginin kontti haluaisi tallettaa jotain ilman, että se kiertää web-selaimen kautta? – Ville Tirronen

In GitLab by @Smibu on Jul 31, 2014, 14:16

@vesal Oletko varma, ettei tätä kannattaisi toteuttaa omana palvelunaan, jolle sekä TIM, että kontit juttelevat? Rajapinnoilla saa aivan samannäköistä kuin silleenkin, että tuo on koodattu TIM:n sisään. Koska tämä on melko suuri kokonaisuus, niin oletettavaa on, että sitä haluttaisiin kuitenkin protoilla erikseen ja tehdä mahdollisesti vaihtoehtoisia testiversioita. – Ville Tirronen

In GitLab by @Smibu on Jul 31, 2014, 14:29

Siis tavallaan tämä on TIMin oma palvelu. Minusta sen vaan kannattaa pyöriä samassa kontissa kuin TIM, koska jos toinen on nurin, ei toisellakaan tee mitään. Eli tuohan ei millään tavalla ota kantaa siihen, missä osoitteessa tuo palvelu on. Se voi olla eri osoitteessa, mutta koska sen TICKET-arvon muodostaa TIM, on olisi järkevää että vastausken tallentava palvelu pääasee kiinni samaan tietokantaam jotta tietää mitä käyttäjää ja tehtävää tuo tiketti edustaa. Mutta minusta tämä ei siis ole TIMin python koodissa vaan saamasta kontista tulevassa eri osoitteessa oleva palvelu, – Vesa Lappalainen

In GitLab by @Smibu on Jul 31, 2014, 14:31

@vesal Entäpä, jos haluaisi käyttää noita monivalintoja jollain muulla sivulla kuin TIM:ssä? Tämä olisi minulle tärkeää, niin voisin siirtyä edes hitaasti omasta systeemistä timiin sillä, että koodaan uudet palat tim-yhteensopivina plugareina. Jos tuo tehtäväpalvelu on naitettu tiukasti timiin, niin en voi tehdä sitä. – Ville Tirronen

In GitLab by @Smibu on Jul 31, 2014, 14:34

Tuo toinen kysymys "kiertää selaimen kautta"? Kiertääkä tqavatra selaimen kautta jos plugininpalvelin lähettää johonkin URLiin tavaraa? Ilan jonkinlaista tiketti-systeemiä en uskaltaisi antaa toisen pluginin suoraan tallettaa tietoa vai minkälaista käyttötapausta ajattelit? Plugin saa toki tallettaa tiedot suoraan itselleenkin noiden user ja taskId tietojen perusteella. – Vesa Lappalainen

In GitLab by @Smibu on Jul 31, 2014, 14:35

Todennäköisesti yksi pluginin palvelu pitää joka tapauksessa olla sellainen, mikä vastausten selailuun näyttää vastaukset järkevässä muodossa. Eli joku kutsu muodossa plugin/showAnswerHTML/?userAnswer=...&userPoints=

Esimerkiksi CS-modulin osalta ajattelin että userAnswer on käyttäjän kirjoittama lähdekoodi JA tuloksen syntyneen kuvan URL. Jos nämä kaksi tietoa toimitetaan TIMille vaikka JSONiin pakattuna, niin niiden näyttäminen sellaisenaan on aika hölmöä. Siksi vastausten selauspalvelu pyytää CSRun plugginilta HTML:än siitä, miten tämä data näytetään. Tässä tapauksessa tuottaisin HTML:än, jossa koodi on PRE tagissa ja kuva IMG attribuutissa, jolloin opettaja näkee heti millaisen koodin kirjoitti ja mikä oli tuloskuva. Tulos voi olla myös kääntäjän virheilmoitus tai konsoliohjelmassa ohjelman tuloste. – Vesa Lappalainen

In GitLab by @Smibu on Jul 31, 2014, 14:37

@vesal Jos plugin kertoo miten vastaus formatoidaan, niin se kyllä puhuisi sen puolesta, että plugin myös tallettaa vastaukset... – Ville Tirronen

In GitLab by @Smibu on Jul 31, 2014, 14:42

en vain haluaisi jokaiseen pluginiin erikseen rakentaa sitä tallentamista. Joskus sanoit että voisi olla yhteinen tietokanta ja tämä on melkein sama asia, tässä vaan on tarkasti speksattu se mitä operaatioita saa tehdä. Pluginien suora pääsy yhteiseen tietokantaan on minusta suurempi riski kuin ohut rajapinta, Tuota vastausten "tallenninta" voi ajatella tietokannan rajapintana. Pisteet kannattaa joka tapauksessa olla suoraan TIMin puolella, koska muuten niiden summien metsästäminen eri plugareita on melkoisesti työläämpää. Ja koska pisteet ja vastaus kuuluvat yhteen, en haluaisi niitä erottaa eri paikkaan. Mutta minusta plugari saa tallettaa itsekin tuon tiedon jos haluaa. – Vesa Lappalainen

In GitLab by @Smibu on Jul 31, 2014, 14:44

@vesal Ottaisitko tämän kortin tehtäväksesi? – Ville Tirronen

In GitLab by @Smibu on Jul 31, 2014, 14:45

Olin vähän Mikalle tätä työntämässä koska kommentit ja vastaukset ovat jollakin tavalla TIMin tietokantaa. – Vesa Lappalainen

In GitLab by @Smibu on Jul 31, 2014, 14:50

Olisiko se niin, että jos tuo käyttäjän vastaus olisi JSON, niin aian ei tarvitsisi edes tehtä tuota näyttävää komponenttia, kun JSON osattaisiin välttävästi purkkaa näyttimen puolellakin. Mun käyttötapauksessa näyttö olisi siis tyyliin (ilman pluginin näytintä): code: System.Console.WriteLine("kukkuu"); output: kukkuu

tai kuvan tapauskessa imgURL: http://tim-beta.it.jyu.fi/csimages/52cded40-a3e0-448f-bd53-edc4dce119bf.png – Vesa Lappalainen

In GitLab by @Smibu on Aug 1, 2014, 11:55

Jos nuo vastaukset tallennetaan TIMin kantaan, niin näin olen sen miettinyt:

Kannassa on siis taulu nimeltä Block, jolla voi olla alatyyppejä miten paljon tahansa (Document, Comment, Note, Answer jne.). Taulussa on sarakkeet:

id INTEGER NOT NULL,
latest_revision_id INTEGER NULL,
type_id INTEGER NOT NULL,
description VARCHAR(100) NULL, -- parempi nimi voisi olla: tag
UserGroup_id INTEGER NOT NULL,

(Tarvittaessa katso repossa timApp/schema2.sql.) Jos ryhmään Y kuuluva käyttäjä tekee tehtävän taskXX, niin se tallennettaisiin näin:

Block(id=1, type=Answer, description="taskXX", usergroup=Y)
Block(id=2, type=Points, description="15", usergroup=Y)

Vastauksen sisältö menee tiedostoon ja halutessa versiohallintaan. Luodaan myös relaatiotauluun (BlockRelation) rivi, joka sanoo, että tuo pistemääräblokki liittyy tuohon vastaukseen.

Kuulostaako yllä oleva järkevältä?

Pitäisikö myös olemassaolevat tehtävät jotenkin rekisteröidä kantaan? Voisi olla tyyliin:

Block(type=Task, description="taskXX", usergroup=tehtävän omistaja)

In GitLab by @Smibu on Aug 1, 2014, 13:27

Kuinka vastausten ja pisteiden historia ja aikaleimat? – Vesa Lappalainen

In GitLab by @Smibu on Aug 1, 2014, 13:43

@vesal Jos myös pisteistä halutaan historia, niin sitten pistemäärä täytynee tallentaa tiedostoon, jotta sen voi commitoida versiohallintaan dokumenttien tapaan. Aikaleimat tulevat versiohallinnan avulla automaattisesti.

In GitLab by @Smibu on Aug 1, 2014, 15:05

joskus olisi mielenkiintoista seurata sitä historiaa, että miten pisteet ovat muuttuneet (ja kenen toimesta erityisesti silloin kun niitä muut saavat muuttaa) – Vesa Lappalainen

In GitLab by @Smibu on Aug 5, 2014, 14:06

Tuossa omassa ehdotuksessani on se vika, että mitä tapahtuu, jos ryhmä muuttuu myöhemmin. Eli jos lisätään ryhmään henkilö, niin pitäisi muodostua uusi ryhmä. Tämän voisi ratkaista ainakin niin, että UserGroup-taulussa on CanEdit-sarake, joka kertoo, voiko ryhmää muokata. Jos ei, niin ryhmää muokattaessa luodaan uusi ryhmä ja palautetaan sen tunniste. Eli silloin kun ryhmä liitetään johonkin vastaukseen ensimmäistä kertaa, niin CanEdit-arvoksi tulisi false.

Tänään tuli esille toisenlainen ehdotus tehtävien tallentamiseen. Luotaisiin kaksi uutta taulua tietokantaan. Eli on taulu, jossa on vastaukset:

aid |   taskId | answercontent | points |      timestamp
  1 | lumiukko |             3 |    1.5 | 4.9.2014 15:30
  2 | lumiukko |             2 |      3 | 9.9.2014 14:40

ja toinen taulu, joka liittää opiskelijat vastauksiin:

aid | uid
  1 | vesal
  1 | kalle
  2 | vesal

Tuossa mietittävänä on se, pitäisikö vastauksen sisällön olla kannassa vai tiedostossa. Vesa ehdotti, että voisi määrittää jonkun rajan, jota isommat vastaukset menevät tiedostoon.

miten taataan se, ettei laita kavereita vastaajiksi, vaikkeivät ole paikalla.

Jotenkin tuntuu, että tätä on mahdoton ratkaista luotettavasti. Joka tapauksessa mun mallissa voisi olla niin, että kun ryhmään lisätään henkilö, niin tuon henkilön täytyy varmistaa ryhmään liittyminen. Tietysti ryhmän luonnin jälkeen kuka tahansa ryhmän jäsen voi laittaa ryhmän tekijäksi mihin tahansa tehtävään, jollei ole mitään muuta tarkistusta. Voisi lisäksi vaatia sen, että jokaisella ryhmän jäsenellä on aktiivinen istunto käynnissä tehtävää palautettaessa, mutta sitten yhdellä koneella tekeminen ei onnistu (vai onnistuuko?).

In GitLab by @Smibu on Aug 5, 2014, 14:47

@Smibu @villetirronen Mietin tuossa, että kannattaako oikeastaan tallettaa kantaan jokaista vastausta jos se answer json talletetaan "kommentiksi" versiohallintaan tms. Historian saa sieltä. Kannan tarkoitus on nopeasti antaa dataa yhteenvetoja varten ja miellellään käyttäjän viimeinen vastaus tähän kysymykseen. Eli tuo answercontent olisi jsonina sellaisenaan, jonka lisäksi state.points ja state.tags tulisivat. Tags sisältää pluginin vastauksesat löytämät "tägättävät" asiat. Monivalinnassa jossa vain yksi oikea, se on käytännössä se käyttäjän vastaus. Ohjelmakoodissa se voisi olla esim lista:

sulut, public, Main

ja silloin voidaan "insitu" kysymyksessä näyttää että 70% älysi laittaa sulkuja koodiin, 50% sanan public jne.

Monivalinnassa missä on monta oikeata, tuo on lista (joka tulee state.tag JSON listana) käyttäjän ruksimien vaihtoehtojen numeroita (tai tunnisteita))

Eli tuo kanta voisi olla myös muotoa:

answers:

aid |   taskId        | user  | answercontent | points |      timestamp
   1 | 22.lumiukko | vesal |   { choice:  3}   |    1.5   | 4.9.2014 15:30
   2 | 22.lumiukko | kalle  |   { choice:  3}   |    1.5   | 4.9.2014 15:30

ensimmäisen vastauksen jälkeen jonka kalle ja vesa tekivät yhdessä ja kun vesal antaa yksin toisen vastauksen, kanta olisi

tags: aid | taskId | user | answercontent | points | timestamp 1 | 22.lumiukko | vesal | { choice: 2} | 3 | 9.9.2014 14:40 2 | 22.lumiukko | kalle | { choice: 3} | 1.5 | 4.9.2014 15:30

aid   | tag
  1 |   2 
  2 |   3

Tuohon on lisätty siis myös dokumentin tunniste tehtväb id:n eteen jotta siitä tulee yksikäsitteinen.

Ohjelmakoodin tapauksessa answercontet olisi esim:

code: ohjelmeakoodia.... imageUrl: http://tim.it.jyu.fi/images/22.lumiukko/vesal/123453.png

Ryhmän vastatessa (se on myöhemmin ratkaistava käyttöliittymäkysymys, että miten ryhmä annetaan) kaikille ryhmäläisille laitetaan oma rivi (tai korvataan edellinen). Tämä vähän replikoi dataa, mutta toisaalta ryhmävastauksia tulenee olemaan murto-osa yksittäisistä vastauksista. Ja moni tehtävä ei tuota ehkä lainkaan riviä tuohon tags-tauluun.

Tyrmätkää/hyväksykää :-) – Vesa Lappalainen

In GitLab by @Smibu on Aug 5, 2014, 15:07

Miten taataan ettei ryhmään laita muita:

Tässä voisi olla liittym, jolla ryhmä muodostetaan dynaamisesta, eli jokainen ryhmäläinen "kirjaantuu" istuntoon mukaan (ja tieto haudataan cookiehen tai oikeastaan sen antamaan sessioon, jolloin ryhmä ei ole voimassa muulta koneelta). Ryhmäläinen voi kirjaantua ulos sessiosta ja muut jäävät. Kommentteina ryhmän tapauksessa VIEW-modessa näkyy a) kaikkien ryhmäläisten kommentit (or) b) kommentit joita kaikki ovat antaneet (and)??? c) 1. kirjaantujan kommentit?

Tämä vaatisi sen verran, että vuorotellen käydään kirjaantumassa. Silloin kuitenkin ainakin mun käyttötapauksessa toimisi ihan kätevästi, koska mulla näyttää väki pääteohjauksissa istuvan melkein alusta asti kimpassa ja tekevät yhdessä tehtäviä. Toimisi paremmin kuin demowww nyt.

Jos tilaisuudessa on kiertävät ryhmät (pakko vaihtaa pari vähän väliä), ei ehkä ole niin mukavaa, mutta jos ryhmä pysyy koossa edes muutaman tehtävän ajan tai tehtvä kestää 15-30 min, ei ehkä liian työlästä. – Vesa Lappalainen

In GitLab by @Smibu on Aug 5, 2014, 15:45

@vesal AO. ehdotus näyttää olevan ok. – Ville Tirronen

In GitLab by @Smibu on Aug 5, 2014, 18:58

Pyörälenkin aikana mietin vaatimusta: "mutta selaamisessa opettaja näkee vanhemmankin ryhmässä tehdyn version"

Tuo ei toteudu tuossa minun tietokantaehdotuksessani. Edellisessä (Mikan kirjaamassa) se toteutuisi, mutta siinä on vaikeampi vastata esim. kysymykseen: "mikä on vesal käyttäjän viimeisin vastaus tehtävään '22.lumiukko'". Ja Mikan kirjaaman version "vika" on myös suurempi tietokannan tilan kulutus. Jos kumpaakaan ei katso ongelmaksi (eli osaa joku tehdä SQL:iä jotka vastaavat vaatimuksiin), niin OK. Yhdistetään nuo kaksi versiota, nin että Mikan versioon vielä se tags-taulu. – Vesa Lappalainen

In GitLab by @Smibu on Aug 6, 2014, 09:16

@vesal Lisäsin tuohon ylös nyt kannan kuvauksen. Ilmeisesti vastaukseen voi liittyä useampi tagi? Muulloinhan sille ei tarvitsisi omaa taulua vaan se voisi Answers-taulussa olla omana sarakkeenaan.

In GitLab by @Smibu on Aug 9, 2014, 13:58

Joo, yhteen vastaukseen voi tulla monta tagia, joskus tuosta voisi tuohon esimerkinkin laittaa. Monivalinta, josta voi valita useamman kohdan, on yksi esimerkki tällaisesta. Ohjelmakoodissa se voisi olla vaikka ["sulut","main","ehtolause"] – Vesa Lappalainen

In GitLab by @Smibu on Aug 25, 2014, 14:58

Tehtävätietojen talletus on TIMin puolella valmis, poislukien mahdolliset bugit. Ainakin MCQ-pluginin vastaus näytti tallentuvan ihan oikein. Siirrän tämän tuotantoon.

In GitLab by @Smibu on Nov 14, 2017, 24:42

closed

TIM-JYU / TIM

Tehtävätietojen talletus TIMiin #694

Tietokannan rakenne tehtävien vastausten ja pisteiden talletuksen osalta