Taulukolle automd-attribuutti #1128

Open dezhidki opened 6 years ago

In GitLab by @Rampastring on Jul 8, 2018, 18:23

Jos soluun syöttää markdown-sisältöä, sitä ei kuitenkaan tulkita markdowniksi ellei solun sisältöä aloiteta md: -merkinnällä.

automd-attribuutin kanssa kaikki solut saisivat automaattisesti md-käsittelyn.

In GitLab by @vesal on Jul 9, 2018, 16:33

Toteutusvaihtoehtoja:

jokaisen muokkauksen yhteydessä tarkistetaan että solun edessä on md: ja kun tullaan editoriin, niin mahdollinen md: poistetaan ettei se hämää käyttäjää. Haitta: YAML-muotoisessa editoinnissa käyttäjä joutuu lisäilemään noita ja ne voivat hämätä käyttäjää
Siinä vaiheessa kun YAML annetaan dumbolle, lisätään nuo md: (myös TeX-versioon)
Dumbolle kerrotaan mitkä attribuutit käsitellään aina md: (vaatii Haskell-koodausta). Vaikeuskerrointa lisää se, että itse sisältöarvo (vai mitä nimeä siitä käytetään), voi olla esitettynä hyvin monella (monellako???) eri tavalla.

In GitLab by @Rampastring on Jul 10, 2018, 10:57

Minusta toteutusratkaisu 2 kuulostaa parhaalta. Onko tilanteita, jossa halutaan ettei osa soluista saa markdown-käsittelyä, mutta muut saavat? Minulle ei tule sellaisia mieleen, sillä markdown-merkintä kuitenkin mahdollistaa kaiken olennaisen sisällön syöttämisen soluihin.

Haskellia olen kirjoittanut funktio-ohjelmointi 1 -kurssin verran kolme vuotta sitten, mutta se ei välttämättä riitä Dumbon muokkaamiseen.

In GitLab by @vesal on Jul 10, 2018, 11:04

OK, kokeile sitä 2)

Kannattaa varmaan tehdä sinne taulukon python koodiin joku funktio prepare_to_dumbo tms jota kutsutaan ennen lohkon viemistä dumbolle. Pitää huomata että sinne viedään kerralla monta lohkoa ja saadaan v astauksena monta muutettua lohkoa. Tuleeko siis siihen joku silmukka, joka timtablen sattuessa kutsuu tuota timtablen ko funktiota.

Kannattaa saman tien miettiä sen verran yleisemmin että sama logiikka toimii millä tahansa pluginilla, eli kaikilla plugineilla olisi tuo. Toistaiseksi vain siis timtable osaisi siihen reagoida, mutta voisin saman matkia sitten myös questions-pluginiin. Hyvässä tuurissahan tuon voisi tehdä aika pitkälle yleisetikin niin, että kullekin pluginille luetellaan ne attribuutit, jotka menee md-käsittelyyn. Ja se yleinen funktio lisää niihin tuon md:. Jos joskus löytyy joku haskell-taitoinen, niin tuo sitten voisi nopeutua jos se tehtäisiin siellä Haskelin exe.ssä. Python on aika hidas noissa.

In GitLab by @Rampastring on Jul 10, 2018, 11:21

created branch 1128-taulukolle-automd-attribuutti

In GitLab by @Rampastring on Jul 10, 2018, 19:18

En ole oikein (vielä) tutustunut plugineiden pohjimmaiseen koodiin, tai myöskään siihen, että miten lohkoja käsitellään. Mitä tältä "minkä tahansa pluginin" toiminnolta varsinaisesti halutaan? Jokaiselle pluginille tulisi prepare_to_dumbo -funktio, jota kutsuttaisiin automaattisesti?

TimTablen koodissa yksinään tämän automd-attribuutin voi nähdäkseni tehdä melko helposti.

In GitLab by @vesal on Jul 10, 2018, 19:59

En ole oikein (vielä) tutustunut plugineiden pohjimmaiseen koodiin, tai myöskään siihen, että miten lohkoja käsitellään. Mitä tältä "minkä tahansa pluginin" toiminnolta varsinaisesti halutaan? Jokaiselle pluginille tulisi prepare_to_dumbo -funktio, jota kutsuttaisiin automaattisesti?

TimTablen koodissa yksinään tämän automd-attribuutin voi tehdä helposti.

Joo, sitten kun sen on tehnyt tuolle, niin rupeaa näkemään yleistyksen miten sen tekisi esim Questions-pluginille. Eli hyvin pitkällehän se on luetella sallittuja ja kiellettyjä attribuutteja tavalla tai toisella. Siis yleisesti. Jossakin erityispluginissa toki säännöt voivat olla monimutkaisempia.

Mutta silloin suurelle osalle plugineja voisi kutsua samaa funktiota, jolle vain vietäisiin tuo attribuuttilista parametrina. Eli pluginissa voisi olla (optionaalinen, saadaan selville reqs-kutsulla, ks: https://tim.jyu.fi/view/tim/TIMin-kehitys/Plugin-speksi#pluginreqs-get)

kutsut: get_automd_attributes ja sitten tarvittaessa hienosäätöä varten tuo prepare_to_dumbo. Ehkä niin että jos pluginkohtainen prepare_to_dumbo tarvitaam niin se voisi sisäisesti kutsua ensin tuota attribuuttilistaan perustuvaa karsintaa ja sitten karsia/lisätä sen päälle jotakin tarkempaa. Mutta saattaa olla että useimmile plugineille riittäisi tuo ihan TIM-koodissa toteutettu attribuutteihin perustuva muokkaus, jolloin sama toimi monelle pluginille. Ainakin video-pluginille (ja siis sitä kautta myös pöytäkirjamakroissa käytetylle pluginille). Mielestäni myös kyselypluginille, sen attribuuteista on tuolla:

https://tim.jyu.fi/view/tim/ohjeita/qst

eli tuossa automd ei sallisi esim attribuutteja:

  answerFieldType
  matrixType
  questionType

mutta mmuut saisivatkin mennä md-käsittelyyn koska ovat näkyvää tekstiä.

Ja tuossa tapauksessa ei edes taitaisi tulla vaihkoa vaikka olisikin:

   answerFieldType: radio

tilalle

   answerFieldType: md: radio

(pitääköhön tuo nyt lainausmerkittää, joka tekee pienen haasteen???)

Eli melkein timtablen käsittely on vaikeampi kuin tuo qst.

Mutta se abstraktio selviää kun kirjoittaa sen koodin tuolle timtablelle ja sitten esim tuolle qst:lle ja huomaa mitä niissä tulee yhteistä.

Pistin erillisen postin jossa pohdin hieman tuon yhteyttä

https://gitlab.com/tim-jyu/tim/issues/519#note_87143941

hakutulosten näyttämisen rajoitteisiin.

In GitLab by @vesal on Jul 10, 2018, 20:18

En ole oikein (vielä) tutustunut plugineiden pohjimmaiseen koodiin, tai myöskään siihen, että miten lohkoja käsitellään. Mitä tältä "minkä tahansa pluginin" toiminnolta varsinaisesti halutaan? Jokaiselle pluginille tulisi prepare_to_dumbo -funktio, jota kutsuttaisiin automaattisesti?

Siis karkeasti näin:

Kun mennän läpi lohkoa, niin jos lohko on plugin ja siinä on automd: true

onko pluginille (tyypille, esim timtable) attribuuttilista?
- on: kutsutaan timin omaa prepare_to_dumbo(lohko, attribuuttlista)
- ei: onko pluginille oma prepare_to_dumbo?
  - on: kutsutaan sitä plugin.prepare_to_dumbo(lohko)
  - ei: lohkolle ei tehdä mitään
lohko viedään dumbolle

Tuossa voi nopeutta asioita jos yhdelle plugin-tyypille voitaisin viedä kerralla kaikki lohkot jotka ovat sitä plugin tyyppiä, sillä eri palvelimella olevan pluginin kutsuminen on hidasta.

Sellainenhan on nytkin plugineissa oleva multihtml reitti:

https://tim.jyu.fi/view/tim/TIMin-kehitys/Plugin-speksi#pluginmultihtml-post

Jos attribuuttilista on annettu sen yhden mailin

https://gitlab.com/tim-jyu/tim/issues/519#note_87143941

mukaisesti regexp-listana, niin silloin on eduksi että nuo listat olisi kerran käännetty valmiiksi "regexp-tilakoneiksi" jolloin vertailu nopeutuu kun sitä tehdään useille sanoille lyhyessä ajassa.

Turhat md:t hidastavat dumbo-käsittelyä, koska silloin jokainen attribuutti-arvo annetaan erikseen pandocille. Hidastaako tämän enemmän vai vähemmän kuin se että Python koodissa tutkitaan onko md:n laittaminen järkevää vai ei, sitä en osaa sanoa. Saattaa jopa olla että kun dumbo on käännetty exe, se tekee nopeammin turhan md-käsittelyn kun Python koodi tutkii että tarvitaanko md:tä. Tämä pitäisi kokeilla niin, että ottaisi esim Ohj1-monisteesta kopion, ja laittaisi KAIKKIEN attribuuttien eteen md: ja katsoisi hidastuuko monisteen käsittely paljon.

Jos ei, niin dumboa voisi ehkä jopa muokata niin, että se käsittelee kaikki attribuutti md:nä. Tosin en olekkaan enää varma saako käsitellä, eli jos on

  width: 25

tai

  width: md: 25

niin tuleekohan noista sama tulos ulos dumbosta?

Kokeile.

In GitLab by @vesal on Jul 11, 2018, 15:15

Saitko Rami mitään tolkkua mun jutuista?

In GitLab by @Rampastring on Jul 11, 2018, 15:41

Ainakin osittain, en ole varma ymmärsinkö ihan kaiken.

Tutustuin tässä pluginien speksiin ja yleiseen pluginien käsittelyn lähdekoodiin, ja onnistuin toteuttamaan automd:n näin aluksi vain TimTablelle.

Alunperin luulin, että plugin itse muuttaa markdowninsa HTML:ksi, mutta sainkin selville, että TIM itse heittää plugin-kappaleen Dumbolle käsiteltäväksi ennen kuin kappale viedään itse pluginille. Siten TimTable itse ei voisi "nykyisellä tavalla" heittää sinne solujen alkuun sitä md: tä, koska ne md:t muutetaan HTML:ksi jo ennen kuin kappale tulee TimTablelle. Tätä varten kai tarvittaisiinkin attribuuttilista, että TIM voisi itse ennen pluginia käydä heittämässä ne md:t paikoilleen niille attribuuteille, mille se tarvitaan.

En nyt kuitenkaan (ainakaan vielä) toteuttanut attribuuttilistaa, vaan lisäsin pluginien reqs:iin vaihtoehdon, jolla plugin voi kertoa, että se antaakin markdowninsa Dumbolle itse multihtml-reitin yhteydessä, jolloin TIMin ei tarvitse sitä tehdä. Lisäsin tämän vaihtoehdon TimTablen palauttamiin reqs:eihin. Sitten TimTablen multihtml-reittiä kutsuttaessa TimTable käy nyt itse taulukkokappaleen läpi ja lisää kaikkiin tarvittaviin taulukon soluihin sen md:n alkuun ennen kuin antaa kappaleen Dumbolle. Dumbo-käsittelyn jälkeen kappale palautetaan JSONina TIMille niin kuin yleensäkin. Nähdäkseni tämä oli puhtaasti TimTablen kannalta helpoin toteutusratkaisu (solut kun voivat olla myös esim. ihan vain mitä tahansa puhtaita merkkijonoja), joskin attribuuttilista voisi vaatia yleisesti vähemmän koodia jos muille plugineille tehdään vastaavaa.

In GitLab by @Rampastring on Jul 11, 2018, 16:26

https://gitlab.com/tim-jyu/tim/merge_requests/7/diffs?commit_id=3055b63b6f8699a848866ce4db5b5230d5a586ae

In GitLab by @vesal on Jul 11, 2018, 16:36

Alunperin luulin, että plugin itse muuttaa markdowninsa HTML:ksi, mutta sainkin selville, että TIM itse heittää plugin-kappaleen Dumbolle käsiteltäväksi ennen kuin kappale viedään itse pluginille. Siten TimTable itse ei voisi "nykyisellä tavalla" heittää sinne solujen alkuun sitä md: tä, koska ne md:t muutetaan HTML:ksi jo ennen kuin kappale tulee TimTablelle. Tätä varten kai tarvittaisiinkin attribuuttilista, että TIM voisi itse ennen pluginia käydä heittämässä ne md:t paikoilleen niille attribuuteille, mille se tarvitaan.

Noihan se kai aluneprin on ollutkin että plugin tuottaa oman HTML:änsä. Mutta siten kun haluttiin että plugin voi sisältää myös md-merkintöjä, lisättiin tuo että plugin käy ensin dumbolla joka md: alkuiset attribuutit muuttaa md-sääntäjenm ukaan joko html:ksi tai TeXiksi.

Sitten on pluginin vuoro muuttaa oma koodinsa html:ksi (tai TeXiksi) ja nyt jos joku attributti on valmiiksi html:ää, niin se sitten on. Tyypillinen tapaus on esim header tai stem.

Mutta esim cs-pluginin byCode-attribuuttia ei missään nimessä saa muuttaa html:ksi, sillä silloin vaikka Pythonin #-jotakin muuttuisi 1. tason otsikoksi.

Ja siksi tuohon enne dumbolle antamista nyt tarvitaan tavalla tai toisella se että dumbolle voidaan kertoa mitkä kentät muutetaan md-säännöillä ja siksi siinä 1. kierroksella lisätään ne md: sopivaan paikkaan (kunnes dumbolle voidaan videä se attribuuttilista jotka se saa muuttaa kyselemättä).

Esim. mcq ja mmcq pluginit tekevät itse sisäisesti tuon md-muunnoksen kun Ville on tehnyt ne Haskelilla ja Haskell voi suoraan kutsua sitä Pandocia sopivilla attribuuteilla ja siksi mmcq ja mcq plugineissa ei tarvitse olla sitä md: attribuuttia. Eli niitä plugineja ei kierrätetä periaateessa tuon dumbo kautta. Jos pandoc-kutsu olisi halvempaa, niin pluginit voisivat itse kutsua sitä, mutta koska se nyt vaatii palvelun kutsumusta (joka dumbo itse asiassa aika pitkälle onkin), niin kutsuja ei kannata tehdä yksitellen ja siksi dumbolle viedään iso joukko lohkoja jotta se muuttaa ne kaikki kerralla.

JOs (???) timtable on Timin sisäinen plugin, niin siihen oleva kutsut ovat hyvällä tuurilla normaaleja aliohjelmakutsuja ja siksi niitä muunnoksia ovi tehdä plugin kerrallaan. csPlugin taa son palvelu jota kutsutaan http-protokollan ylitse, joten sinne tehtävät kutsut ovat hitaampia ja sinne on pakko viedä taulukollinen plugineja kerralla jotta yhdellä kutsulla saadaan enemmän tuloksia. Ja qst on myös sisäinen plugin, joten sitäkin voisi kutsua aliohjelmakutsuina. Tosin sitä taidetaan kutsua myös http-rajapinnan läpi, mikä hidastaa koodia. Plugin-määrittelyyn voisi lisätä myös sen, millä protokollala kutsutaan, jolloin sisäiset kutsut olisiva mahdollisa. Nyt noita hhttp-protokollakutsuja tulee yksi/plugintyyppi, eli ei hirveästi (sen multihtml ansiosta).

In GitLab by @vesal on Jul 11, 2018, 16:50

Joo, tuo nyt toteuttamasi tapa voi käydä tuhoisaksi suorituskyvylle, sillä se kutsuu jokaiselle attribuutille dumboa ja jokaienn dumbo-kutsu on hidas.

Kaikissa em tavoissa taulukkotarkoittaa yhden plugintyypin (esim qst tai csplugin) kaikkia esiintymiä dokumentissa. Siitä en ole varma onko jopa nyt niin, että kaikki pluginit on dumbolle viety yhdesä taulukossa.

Eli karkeasti "vanha tapa":

tim: pluginit taulukoon -> plugin:multhml palauttaa taulukollisen html:ää

"Uusi tapa":

    tim: pluginit taulukkoon -> dumbo muuttaa md attribuutit
                             -> plugin:multhml palauttaa taulukollisen html:ää

"automd-tapa":

    tim: pluginit taulukkoon -> plugin:prepare_to_dumbo muuttaa md: sopivien attribuuttien eteen
                             -> dumbo muuttaa md attribuutit
                             -> plugin:multhml palauttaa taulukollisen html:ää

"automd-tapa" (attribuuttilistalla):

    tim: pluginit taulukkoon -> jos pluginilla attribuuttilista, tim muuttaa listan perusteella md: sopivien attribuuttien eteen
                             -> jos pluginilla on prepare_to_dumbo, plugin:prepare_to_dumbo muuttaa md: sopivien attribuuttien eteen
                             -> dumbo muuttaa md attribuutit
                             -> plugin:multhml palauttaa taulukollisen html:ää

Eli prapare_to_dumbo ei vielä tee html:ää, ainoastaan lisää niitä md ja sitten palaa takaisin ja dumboa kutsutaan vain yhden kerran (tai yhden kerran/plugintyyppi)

Eli ymmärtäisin että kutsu automd-tavassa olisi:

  return json_response(call_dumbo(xxx.prepare_todumbo(plug.values), '/mdkeys'))

In GitLab by @vesal on Jul 11, 2018, 17:04

En nyt kuitenkaan (ainakaan vielä) toteuttanut attribuuttilistaa, vaan lisäsin pluginien reqs:iin vaihtoehdon, jolla plugin voi kertoa, että se antaakin markdowninsa Dumbolle itse multihtml-reitin yhteydessä, jolloin TIMin ei

Joo, tuossa on se vika, että ei-Timin sisään tehdyt pluginit eivät voi tuota kutsua. Pluginhan voisi periaatteessa olla ihan eri palvelmilla.

Jos tuota hetekn kuitenkin haluaa noin, pitää, niin pluginin pitää ensin tehdä siitä taulukosta se muokattu taulukko ja sitten antaa se kokonaisena dumbolle. Mutta silloin ollaankin jo siinä tilanteessa että kannattaa jättää se dumbo kutsu pois ja antaa Timin tehdä se.

Ja attribuuttilistalla tuon prepare (joka saa olla vaihtoehtona) tarve tulee harvinaisemmaksi. Joskushan voi olla jotakin harvinaisempaa, eli attribuutin saa uutta jos se ei sisällä xxx yms. Ja tuollainen on sitten sen prepare hommia.

In GitLab by @Rampastring on Jul 11, 2018, 18:18

Ja siksi tuohon enne dumbolle antamista nyt tarvitaan tavalla tai toisella se että dumbolle voidaan kertoa mitkä kentät muutetaan md-säännöillä ja siksi siinä 1. kierroksella lisätään ne md: sopivaan paikkaan (kunnes dumbolle voidaan videä se attribuuttilista jotka se saa muuttaa kyselemättä).

TimTablella ei ole ennalta määriteltynä kaikkia attribuutteja, vaan taulukon solut voivat olla cellien lisäksi myös melkeinpä mitä tahansa merkkijonoja. Toki taitaisi silti regexpillä onnistua.

Joo, tuo nyt toteuttamasi tapa voi käydä tuhoisaksi suorituskyvylle, sillä se kutsuu jokaiselle attribuutille dumboa ja jokaienn dumbo-kutsu on hidas.

Dumboa kutsuttiin kerran jokaiselle dokumentissa esiintyvälle taulukolle (ei jokaiselle attribuutille). Tosin sain sen muokattua niin, että kutsutaan vain kerran kaikille taulukoille (siltikin TimTablen puolelta).

Siitä en ole varma onko jopa nyt niin, että kaikki pluginit on dumbolle viety yhdesä taulukossa.

Lähdekoodin perusteella olen ymmärtänyt, että kaikki saman tyypin pluginit viedään dumbolle kerralla. Jos dokumentissa on monentyyppisiä plugineja, niin ne viedään erikseen.

Eli prapare_to_dumbo ei vielä tee html:ää, ainoastaan lisää niitä md ja sitten palaa takaisin ja dumboa kutsutaan vain yhden kerran (tai yhden kerran/plugintyyppi)

Pluginia tosin kutsutaan esittämässäsi automd-tavassa kahdesti, mikäli pluginilla on prepare_to_dumbo. Ensin prepare_to_dumbo (jos pluginilla on se) ja sitten vielä multihtml. Nykyisellä väliaikaistoteuteuksella pluginia kutsutaan vain kerran, kun multihtml "sisältää" prepare_to_dumbon. En sitten tiedä, onko tämä suorituskyvyn kannalta kuinka hyödyllistä.

Toki on muita hyötyjä jos automd-käsittelyn siirtää TIMin puolelle. Erityisesti päästään vähemmällä koodilla, jos tulevaisuudessa useampikin plugini hyödyntää automd:ta eikä niiden tarvitsisi itse tarkistella, että onko niillä se automd päällä.

Voin huomenna alkaa katsomaan tämän automd:n yleistämistä TIMin pluginkäsittelyn puolelle.

In GitLab by @vesal on Jul 11, 2018, 18:27

joo, siis yksi hyöty on se, että tavallinen plugin ei voi kutsua dumboa eikä tiedä sen olemassaolosta. siksi sitä pitää kutsua kahdesti. toki jos lähtee siitä, että sisäisiä plugineja ruvetaan suosimaan, niin tuo toteuttamasi tapa voisi olla yksi vaihtoehto jonka plugin voi kertoa reqs kutsussa.

tosin melkein tekisin sitten sisäisten pluginien kohdalla niin, että kutsutaan suoraan metodia, ei rajapinnan kautta, jolloin kutsun hinta tippuu ja kutsuja voi tehdä useampiakin.

eli eri reiteille oli myös vaihtoehtoiset sisäiset kutsut.

In GitLab by @vesal on Jul 11, 2018, 18:28

joo, niin tuo että plugin kutsuu dumboa, taitaa aiheuttaa ongelmia tex tulostukseen, jonne myös pitää lisätä tuo prepare kutsu

In GitLab by @vesal on Jul 11, 2018, 18:31

voiko tätä kokeilla jossakin?

In GitLab by @Rampastring on Jul 11, 2018, 18:45

joo, siis yksi hyöty on se, että tavallinen plugin ei voi kutsua dumboa eikä tiedä sen olemassaolosta. siksi sitä pitää kutsua kahdesti.

Tätäpä en ole ajatellutkaan kun TimTable on ensimmäinen plugin, jonka parissa olen työskennellyt. Ja siellä kutsuttiin dumboa jo ihan projektissa tehdyssä koodissa.

tosin melkein tekisin sitten sisäisten pluginien kohdalla niin, että kutsutaan suoraan metodia, ei rajapinnan kautta, jolloin kutsun hinta tippuu ja kutsuja voi tehdä useampiakin.

Pluginien metodien kutsumiselle suoraan ei tosin taida olla pluginien käsittelyn koodissa mitään valmista tällä hetkellä, niin se vaatisi hieman refaktorointia. Tosin tämän automd:n toteuttaminen vaatii sitä jonkin verran muutenkin.

joo, niin tuo että plugin kutsuu dumboa, taitaa aiheuttaa ongelmia tex tulostukseen, jonne myös pitää lisätä tuo prepare kutsu

Kutsun lisääminen LaTeX-tulostukseen ei vaikuta vaikealta.

voiko tätä kokeilla jossakin?

Ei vielä. Visa on käyttänyt timdevs1-testikonetta, jaetaanko me se? Vai kannattaisiko minun käyttää jotain muuta? Projektin timdevs02 on edelleen olemassa, mutta ei tietenkään läheskään ajan tasalla ja kohtaamieni TIMin asennusongelmien perusteella sen saaminen ajan tasalle voi olla työlästä.

In GitLab by @vesal on Jul 11, 2018, 19:01

Tätäpä en ole ajatellutkaan kun TimTable on ensimmäinen plugin, jonka parissa olen työskennellyt. Ja siellä kutsuttiin dumboa jo ihan projektissa tehdyssä koodissa.

:-)

Pluginien metodien kutsumiselle suoraan ei tosin taida olla pluginien käsittelyn koodissa mitään valmista tällä hetkellä, niin se vaatisi hieman refaktorointia. Tosin tämän automd:n toteuttaminen vaatii sitä jonkin verran muutenkin.

joo, sen verran että kutsuttaisiinko jotakin metodia reitin kautta vai suoraan metodina. Ja reqs pitäisi tämä kertoa. Mutta se riittäisi varmaan kerran kun olisi joku inner_plugin: true

Ja märitelty se minkä nimisiä metodien pitää olla ja mitä niille tuodaan parametrina. Iso hyöty voisi olla se, että sisäiselle metodille voi tuoda parametrina valiita json, kun ulkoisille ne muuttuu html-rajapinnassa merkkijonoksi jotka taas muutetaan takaisin jsoniksi, eli tämä voisi isojen taulukoiden kohdalla nopeuttaa kohtuullisesti.

Kutsun lisääminen LaTeX-tulostukseen ei vaikuta vaikealta.

Ei, se vaan pitää muistaa tehdä :-)

Ei vielä. Visa on käyttänyt timdevs1-testikonetta, jaetaanko me se? Vai kannattaisiko minun käyttää jotain muuta? Projektin timdevs02 on edelleen olemassa, mutta ei tietenkään läheskään ajan tasalla ja kohtaamieni TIMin asennusongelmien perusteella sen saaminen ajan tasalle voi olla työlästä.

Siellä koneella on niitä hakemistoja /opt/tim?

Eli esim timdevs2 käyttööotto vaatisi sen, että /opt/tim2 hakemistoon järkkää oikeat tavarat. Visan kanssa saman "koneen" jakaminen vaatisi kai samassa haarassa työskentelyä ja se voisi olla hankalaa? En ole varma tarviiko tuonne tim2 haaraan pullata kontteja, koska ne taitaa olla vain yhden kerran ja käynistäminen käynnistää niistä vain toisen esiintymän.

Eli hyvässä tuurissa kopioimalla tim1 hakemistosta ongelmatiedostot tim2 hakemistoon, se voisi onnistua kohtuullisella vaivalla.

In GitLab by @vesal on Jul 11, 2018, 19:07

Projektin timdevs02 on edelleen olemassa, mutta ei tietenkään läheskään ajan tasalla ja kohtaamieni TIMin

Tuo:

   https://timdevs0.it.jyu.fi/

on ainakin elossa, eli se m itä edellisessä postissa sanoin /opt/tim2 hakemistosta, niiin tekee /opt/tim0 hakemistolle.

Eli siellä pullaa sen sun haaran ja sitten ./up.sh

Tarvittaessa niitä

   ./docker-compose.sh restart

Tosin taisi kuolla kun kokeili tuota restarttia...

In GitLab by @Rampastring on Jul 12, 2018, 11:40

joo, sen verran että kutsuttaisiinko jotakin metodia reitin kautta vai suoraan metodina. Ja reqs pitäisi tämä kertoa. Mutta se riittäisi varmaan kerran kun olisi joku inner_plugin: true

Plugineita käsittelevällä koodilla on globaali lista plugineista, niin inner pluginin voisi vaihtoehtoisesti sanoa myös siellä.

Ja märitelty se minkä nimisiä metodien pitää olla ja mitä niille tuodaan parametrina.

Miten plugineita käsittelevä koodi pääsisi helpoiten konkreettisesti kutsumaan plugineiden metodeita? Plugineita käsittelevällä koodilla ei nähdäkseni ole tällä hetkellä mitään pääsyä itse pluginien koodiin, se tietää vain pluginien nimet ja kutsuu metodien sijaan reittejä HTTP:n kautta.

Timdevs0:lla voi nyt tosiaan kokeilla tätä taulukon automd:tä:

https://timdevs0.it.jyu.fi/view/testaus-1

In GitLab by @vesal on Jul 12, 2018, 11:46

Vesa

Se voisi olla niin että sisäisistä tehtäisiin staattinen oli jo jolla olisi sovitut metodien nimet

-------- Alkuperäinen viesti -------- Aihe: Re: TIM | Taulukolle automd-attribuutti (#1128) Lähettäjä: Rami Vastaanottaja: vesal@jyu.fi Kopio:

In GitLab by @vesal on Jul 12, 2018, 11:52

Ja tämä globaalin oli on nimi on sitten siellä taulukossa sanottuna

Vesa

In GitLab by @Rampastring on Jul 12, 2018, 14:36

Nyt kun taulukon automd on valmis, niin tein yleiselle automd:lle oman haaransa taulukon haaran pohjalta.

https://gitlab.com/tim-jyu/tim/commit/d24bad7adea7ef0be5551d0ef46d856c98368514

Olennaisimmat asiat löytyy commit-viestistä. Jos plugin on määritelty sisäiseksi plunigiksi siinä globaalissa pluginilistassa, sen metodeja kutsutaan nyt suoraan eikä HTTP:n kautta. Dumbo-muunnoksen tekee taas TIM itse. Automd toimii toistaiseksi vain sisäisille plugineille, ei-sisäiset pluginit taitavat tarvita uuden reitin sitä varten ja sitä sitten kutsuttaisiin HTTP:n yli.

Jotta sisäisen pluginin metodeja voidaan kutsua, sille pitää tehdä luokka. containerLinkissa sitten luodaan globaali instanssi siitä luokasta, ja kutsutaan sen metodeja.

(Tämä commit myös taisi rikkoa LaTeX-tulostuksen sisäisiksi määritellyiltä plugineilta eli toistaiseksi vain TimTablelta, mutta korjaan sen kohta)

In GitLab by @vesal on Jul 13, 2018, 10:06

automad voisi olla oletuksen päälleä ja automd: false pitäisi laittaa jos eitä ei halua.

Ainkain timtablelle kun sitä ei ole vielä julkaista, ehkä myös qst. Muita pitää miettiä, ehkä jopa niihinkin aikanaan.

Annakko suoran linkin muutoksiin miten teit tuon yleisen automd

In GitLab by @Rampastring on Jul 13, 2018, 10:12

Linkki oli jo ylempänä: https://gitlab.com/tim-jyu/tim/commit/d24bad7adea7ef0be5551d0ef46d856c98368514

In GitLab by @Rampastring on Jul 13, 2018, 15:12

Laitoin automd:n päälle uusiin TIMin kautta luotaviin taulukoihin (lisäämällä valmistaulukoihin automd=true). Jos attribuutti puuttuu, niin se tulkitaan vielä edelleen falseksi.

In GitLab by @vesal on Jul 14, 2018, 08:22

timtablella voisi ola automd oletuksena true jos attribuuttia ei olla ja erikseen pitää laittaa false jos sitä ei halua.

mahdollisimman minimaalinen määrä attribuutteja joita käyttäjän tarvitsee muutella

In GitLab by @Rampastring on Jul 16, 2018, 15:49

Pitäisikö automd olla päällä oletuksena vain timTablella? Vai muillakin plugineilla? Oletustilan voisi sanoa siinä pluginitaulussa...

In GitLab by @vesal on Jul 16, 2018, 17:43

joo kaikilla sisäisillä ja muutkin voisi at ominaisuutta pyytää

Vesa

In GitLab by @vesal on Jul 16, 2018, 18:29

Pitäisikö automd olla päällä oletuksena vain timTablella? Vai muillakin sisäisillä plugineilla?

Tai oikeastaan voisi olla paras jo tuo tulisi reqs tuloksena. Joku

"automd_default" : true

niin jokaiseen pluginiin oiv tuon tehdä miten haluaa sitten. Toki toistaiseksi sisäisiä on aika vähän (timtable ja qst, tuliko tituksessa muita lisää?) ja niissä se voi olla päälle. Laitan varmaan jossakin vaiheessa myös imagex:ään, svn/video ja csPluginiinkin. Sitten kun voi attributeilla luetella sen mitä muutetaan.

In GitLab by @Rampastring on Jul 17, 2018, 18:12

Pluginin reqsissä voi nyt sanoa että default_automd = True https://gitlab.com/tim-jyu/tim/commit/4e1ad39b7a8a051946ae0dcf0fce821c5938539c

Mitenkäs attribuuteilla luetteleminen tarkalleen toimisi? Kävisikö se kappaleen jokaisen attribuutin läpi ja laittaisi md: kaikkien niiden arvojen alkuun, jotka täsmää johonkin listassa olevaan? Olisiko regexille käyttöä? Pidettäisiinkö attribuuttilistan alkioita oletuksena regexinä tms.?

In GitLab by @vesal on Jul 18, 2018, 24:28

Mitenkäs attribuuteilla luetteleminen tarkalleen toimisi? Kävisikö se kappaleen jokaisen attribuutin läpi ja laittaisi md: kaikkien niiden arvojen alkuun, jotka täsmää johonkin listassa olevaan? Olisiko regexille käyttöä? Pidettäisiinkö attribuuttilistan alkioita oletuksena regexinä tms.?

Joo, noin ajattelin että tarkistetaan onko attribuutti listassa ja jos on, niin md eteen. Lista voi hyvin olla joukko regexpejä. En tiedä saisiko testiä nopeutettua jos sen sisäisesti käsittelisi regexpinä

((a)|(b)|(c))

jolloin yksi testi riittäisi sisäisesti. Ihannetilanteessa tuo olisi valmiiksi käännetty regexp, jolloin joka plugin kohdalla sitä ei tarvitse laskea uusiksi.

In GitLab by @Rampastring on Jul 18, 2018, 14:25

Automd attribuuttilistalla on nyt toteutettu ja testattavissa sivulla https://timdevs0.it.jyu.fi/view/testaus-3

qst:n automd-attribuuteiksi on nyt testinä määritetty rows ja questionText

Koodi ei välttämättä ole vielä optimaalista dictien ja listojen käsittelyn osalta. Muutokset on seuraavassa kahdessa commitissa:

https://gitlab.com/tim-jyu/tim/commit/e2f24e4a6074b83eb04f270d926b5962cfa4cc23

https://gitlab.com/tim-jyu/tim/commit/b75b292db7d755f2d1792242f4ccf1363f8c1fab

In GitLab by @vesal on Jul 18, 2018, 14:44

Automd attribuuttilistalla on nyt toteutettu ja testattavissa sivulla

OK, noita attribuutteja on enemmänkin.

Sellainen ongelma näköjään (ehkä Mikan refaktorointi saanut aikaan, pistä jollekin kortille), että jos editoi Lecture View:ssä Edit question, niin hukkaa tuon automd. Samoin näköjään header yms attribuutteja joita tuo tuntee.

Sitten tuon Edit question preview ei ota tätä huomioon, ehkä sekään ei toisin kuulu tähän korttiin, mutta johonkin.

In GitLab by @vesal on Jul 18, 2018, 14:44

Koodi ei välttämättä ole vielä optimaalista dictien ja listojen käsittelyn osalta. Muutokset on seuraavassa kahdessa commitissa:

Varmaa idean voi heittää sitten käytettäväksi jos tämän joskus siirtää kokonaan dumbon puolelle. Eli dumbolle vietäisiin tuo attr lista, niin se saisi hoidella homman sisäisesti.

In GitLab by @Rampastring on Jul 18, 2018, 17:34

OK, noita attribuutteja on enemmänkin.

Listaa on helppo muokata.

Sellainen ongelma näköjään (ehkä Mikan refaktorointi saanut aikaan, pistä jollekin kortille), että jos editoi Lecture View:ssä Edit question, niin hukkaa tuon automd. Samoin näköjään header yms attribuutteja joita tuo tuntee.

OK.

TIM-JYU / TIM

Taulukolle automd-attribuutti #1128