search

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

"Task not found in the document" käännösdokumentissa, jos käännöslohko on viitelohko toisen käännösdokumentin käännöslohkoon #3658

Open dezhidki opened 1 month ago

dezhidki commented 1 month ago

Toistovaiheet

  1. Luo dokumentti 1 ja siihen plugin

    ``` {#suttu plugin="csPlugin" id="LXo1mjpX6GLA"}
header: Tätä voit käyttää suttupaperina
type: text
highlight:
hideBrowser: true
placeholder: "suttupaperi"
button: Tallenna
rows: 10
editorMode: 0
wrap: 60
highlight: 
hide:
 wrap: true
 changed: true
resetText: ""  
copyLink: ""
#floatHeader: Suttupaperi
eagerlyLoadState: true

  2. Tee dokumentille 1 käännösdokumentti 2 ja määritä siihen käännös:

    ``` {r="tr" rp="LXo1mjpX6GLA" rt="LTB4MmE2NGY3M2I=" id="pgfF5CsENLCU"}
header: Detta kan du använda som klottpapper
type: text
highlight:
hideBrowser: true
placeholder: "klottpapper"
button: Spara
rows: 10
editorMode: 0
wrap: 60
highlight: 
hide:
 wrap: true
 changed: true
resetText: ""  
copyLink: ""
eagerlyLoadState: true

  3. Tee dokumentti 3 ja lisää siihen viite dokumentin 1 tehtävälohkoon:

    #- {rd="1" rp="LXo1mjpX6GLA" id="YdLopH6uX8yE"}

  4. Tee dokumentille 3 käännösdokumentti 4 ja muuta syntynyttä käännöslohkoa viittaamaan käännösdokumentin 2 käännöslohkoon:

    #- {r="tr" rd="2" rp="LXo1mjpX6GLA" id="O3q0mvOCWaMu"}

  5. Lisää vastaus pluginiin käännösdokumentissa 2

  6. Mene käännösdokumenttiin 4 ja yritä katsoa tehtävän sisältöä.

    • Jos virhe ei toistu, toista vaiheet 3 ja 4 (eli tee vielä yksi dokumentti+käännös) ja kokeile vuorotellen lisätä vastauksia niihin ja katsella vastauksia

Yllä olevassa esimerkissä virheeksi voi jossain vaiheessa tulla

Error: Task not found in the document: XXX (potentially because of wrong block id hint)

missä XXX on dokumentin 1 nimi.

Virheen lähde on:

https://github.com/TIM-JYU/TIM/blob/da205908c9bb88da7c2842869c1fdf4e1fcc9dd5/timApp/plugin/plugin.py#L1028-L1068

Virhe tapahtuu, kun AnswerBrowser tekee pyynnön /getState.

Virheen todennäköisin syy on se, että vaiheessa 6 AB tekee seuraavanlaisen pyynnön:

/getState?answer_id=1&doc_id=2&par_id=pgfF5CsENLCU&ref_from_doc_id=4&ref_from_par_id=O3q0mvOCWaMu

Tällöin tapahtuu seuraavat asiat /getState-polussa:

  1. Haetaan vastaus ID:llä 1 (tai uusin vastauksen ID)
  2. Parsitaan vastauksen taskID. Käännösdokumenteissa taskIDt ovat samat kuin alkuperäiset dokumentit, eli tässä 1.suttu
  3. Koska polkuun on annettu parametrina par_id, muutetaan taskID muotoon 1.suttu.pgfF5CsENLCU
  4. Yritetään löytää plugin ID:llä 1.suttu.pgfF5CsENLCU. Tätä ei löydy, koska pgfF5CsENLCU on käännösdokumentin lohko ID, mutta nyt haetaan data dokumentista 1 (eli alkuperäinen).

Olennainen huomio: tällä hetkellä /getState-polku ei käytä parametrina annettua doc_idtä!

Korjaus siis vaatisi doc_id-parametrin huomioimista. Vähintään, jos se on annettu, niin taskIDhen asetetaan parametrina annettu doc_id. Tämä kuitenkin pitää testata hyvin tarkasti, sillä tämä voi rikkoa oikeaa logiikkaa. Pitäisi ottaa huomioon ainakin seuraavia asioita:

sijualle commented 1 month ago
  • Meneekö mitään rikki, jos getState hakisi pluginin tiedot ilman doc_id ja par_id -parametreja? Yllä olevat kaksi hakutapaa (answer_id tai task_id) riittävät jo tilan hakemiseksi
  • Onko siis joku tapaus, jossa pluginin tila haluttaisiin hakea (doc_id, par_id)-kaksikolla? Ehkä jos ei jostain syystä tiedetä pluginin taskID, mutta tiedetään pluginin sijainti?

Eikös jompi kumpi (docid tai parid) tarvita aina kuitenkin käännöksiä varten? Siinä getStatessahan haetaan pluginin koko html. Jos tekee getState alkuperäiskielisessä dokumentissa, pluginin otsikot yms näkyy sillä kielellä. Sitten jos tekee getState käännösdokumentissa niin pitäisi saada siinä html:ssä käännetyt otsikot yms.

sijualle commented 3 weeks ago
  • Meneekö mitään rikki, jos getState hakisi pluginin tiedot ilman doc_id ja par_id -parametreja? Yllä olevat kaksi hakutapaa (answer_id tai task_id) riittävät jo tilan hakemiseksi
  • Onko siis joku tapaus, jossa pluginin tila haluttaisiin hakea (doc_id, par_id)-kaksikolla? Ehkä jos ei jostain syystä tiedetä pluginin taskID, mutta tiedetään pluginin sijainti?

Eikös jompi kumpi (docid tai parid) tarvita aina kuitenkin käännöksiä varten? Siinä getStatessahan haetaan pluginin koko html. Jos tekee getState alkuperäiskielisessä dokumentissa, pluginin otsikot yms näkyy sillä kielellä. Sitten jos tekee getState käännösdokumentissa niin pitäisi saada siinä html:ssä käännetyt otsikot yms.

Eikun nyt kun tutkin niin noita varten tuolla getStatessa meneekin tuo ref_from_doc_id ja ref_from_par_id, joiden perusteella haetaan se käännöksen html. Ja nopeasti katsottuna getState heittää poikkeuksen, jos ei anna answerId:tä (josta kaivetaan taskId) tai taskId:tä. Eli ei pitäisi olla tilannetta jossa tiedetään pluginin sijainti mutta ei taskId:tä.

Joskus oli toiveena että samanniminen plugin voisi olla dokumentissa kaksi kertaa, esim yhtä arvonsyöttökenttää voisi olla kiva toistaa useampaan kohtaan (sitä varten text/numericfieldissä on se duplicates-kohta), ja siihen tuo par_id voisi olla hyödyllinen jos kentillä on eri asetuksia ulkoasua tms varten. Mutta tuo on niin huonosti tuettu ominaisuus että mieluummin vaan poistaisi tuon doc_id ja par_id -parametrit kokonaan