Paljon kenttiä sisältävän sivun browseaminen #1420

Open dezhidki opened 5 years ago

In GitLab by @vesal on Jun 22, 2019, 10:05

Jos sivulla on paljon kenttiä, on browseaminen hidasta. Jokaisesta kentästä tulee nyt

   GET /answers/528.ht2/2?_=1561185703828 200
   GET /getState?answer_id=1276&doc_id=528&par_id=fBpPSCzygKr8&ref_from_doc_id=536&ref_from_par_id=MPP1Mirl6Hni&review=false&user_id=2
   GET /getState?answer_id=1276&doc_id=528&par_id=fBpPSCzygKr8&ref_from_doc_id=536&ref_from_par_id=MPP1Mirl6Hni&review=false&user_id=2

Nuo pitäisi saada niin, että kaikki /answerssaadaan yhdellä pyynnöllä ja kaikki sellaiset /getSate toisella, jos pluginin tukee suoraan contenttiin sijoittamista. Erityisesti fields-tyyppisiin on tehtävä tällainen tuki. Silloin getState ei tarvitse muodostaa html:ää, vaan riittää palauttaa answer_id:tä vastaava tallennettu tila. Ja sitten viewCtrl jakelee nämä tilat plugineille. Plugin voi sisällöstä riippuen tukea setContent-metodia eli viewCtrl kyselee tämän erikseen ennen sen ison /answers pyynnön tekemistä. Tällöin yksinkertaisessa tilanteessa myös csPlugin osaisi tämän. Jos plugin ei tue setContent, niin toimitaan kuten ennenkin niiden kohdalla.

In GitLab by @vesal on Jun 23, 2019, 23:07

Varmaan kannattaisi järjestää niin, että pyynnössä on tiedosssa kunkin vastauksen dokumentti, johon se liittyy, jotta hakun vo järjestää dokumentti kerrallaan niin, että ei tarvitse luoda dokuolioita ja lisätä preambleja joka kerta erikseen. Ja silloin oikeuden lienee voi katso dokukerrallaan?

In GitLab by @vesal on Jul 9, 2019, 24:12

Nyt se hakee noita taskusereita kun kursori menee tehtävän päälle.

Mutta eikös se ilman muuta ole tuon "users with answers" taulukon valittu käyttäjä. Ainaostaan silloin kun siinä on monta käyttäjää, se voisi olla myös joku muu lisäksi.

Ei jos yksinkertaisesti sovitaan että form-modessa jaokasiella pluginilla oletuksena opettajan kirjoittama tulos menee valitulle käyttäjälle (senhän tiedot siinä näkyy).

Sitten plugineihin määritellään joku attribuutti, jolla tätä oletusta voi muuttaa ja silloin plugin tippuu pois tuosta pikahausta ja toimii kuten ennenkin.

Tuohon monen vastaajan kohdalla tiedon tallentamiseen liittyy muitakin ongelmia, nimittäin jos on käyttäjät A, B ja C vastanneet yhdessä tehtävään T1. Sitten opettaja katsoo A:n vastausta. Nykyinen ab näyttää että yheteityössä on ollut A,B ja C.

Sitten B onkin itse vastannut tuon jälkeen.

Jos opettaja A:n vastausta katsoessaan tallentaisia A, B ja C, niin B: menettäisi sen uudemman vastauksensa (en tiedä meneekö nyt näin, mutta pelkään...). Eli iilman ab:ta ei ole mitenkään miellekästä tallentaa muille kuin valitulle käyttäjälle. Kukaan ei loogiesti hallitsisi tai ymmärtäisi jos tuon problematiikan yrittäisi selittää. Toki jos kaikki vastaajat on tiedossa, voisi varoittaa että nämä liittyy tähän. Voisi toimia autosave-tilassa, mutta entä js lohkossa on 10 kenttää ja opettaja muuttelee kaikkia ennen Saven painamista ja käyttäjille on sekaisin mikä joukko on yhdessä mihinkäkin vastannut. Toki tuossakin SaveAll voisi jokaisesta epäselvästi kysyä erikseen että kenelle näistä tallennetaan. Tyyliin.

  Kentässä T1 oli aluneprin 3 vastaajaa, kenelle
  tämä tallennetaan:

     [ ] Herra A
     [ ] Herra B
     [ ] Beiti X

Mutta onko tämä jo ylireagointia? Jotta tästä filedeissä olisi merkittävästi hyötyä, pitäisi opettajan jo syöttövaiheessa voida valita kenelle tallentaa. Esim jos tabelFormilla valkkaa kolme opiskelijaa ja laittaa heilla vaikka saman HT päivämäärän kun olivat ryhmässä, niin opettajan syöttö pitäisikin tallentua kaikille kolmelle. Tai opettaja ruksisi kolme kaveria listasta ja kirjoittaisi yhden kohdalle HT1 sarakkeeseen, niin tallentuisi kaikille. Tämä olisi hieno apu tuon kaverina että kun yhtä muuttaa, niin mahdollisesti muuttaisi kaikkia.

Mutta kuinka moni osaisi oikeasti käyttää?

Ja sitten pitäisin muutenkin olla ehkä mahdollisuus valita ryhmiä täytettäväksi. Jos harjoitustöitä tms tehdään ryhmissä. Kuka loisi ryhmät ja muistaisi niiden nimet?

In GitLab by @sijualle on Jul 9, 2019, 24:41

Tuohon monen vastaajan kohdalla tiedon tallentamiseen liittyy muitakin ongelmia

Pääseekö jollain pluginilla testaamaan että miten tuo useamman käyttäjän antama vastaus käytännössä toimii?

In GitLab by @vesal on Jul 9, 2019, 24:51

katso admin ohjeista quicklogin ja sitten kirjaannut ensin sisään yhtenä käyttäjänä ja sitten liityt samaan sessioon toisena käyttäjänä siitä käyttäjännimi painikkeesta ja vastaatte mihin tahansa tehtävään. en tiedö toimiiko textfield, mutta ainakin csplugin jos tekee ensin vaikka c# tehtävän.

mutta huomasin että tuohon liittyy vielä asioita joita pitäisi huomioida myös formtablessa, eli siinäkään ei saisi tallentaa ehkö vain yhdelle käyttäjälle.

In GitLab by @sijualle on Jul 9, 2019, 01:45

tuohon liittyy vielä asioita joita pitäisi huomioida myös formtablessa, eli siinäkään ei saisi tallentaa ehkö vain yhdelle käyttäjälle.

Nyt tableForm (ja jsrunner) lataa sen edellisen vastauksen ennen tallennusta jotta saa edellisen vastauksen muut kentät siihen uuteen vastaukseen mukaan ja siinä voisi samalla katsoa tuon vastauksen muut vastaajat ja laittaa sen vastauksen myös niille. Tosin silloin pitäisi keksiä jo siinä vastauksen hakuvaiheessa joku tapa näyttää taulukossa että tässä vastauksessa on muitakin vastaajia (ehkä joku solun korostus ja selittävä tooltip josta näkee ne muut käyttäjät). Vai pitäisikö tableFormin kuitenkin olla loppujen lopuksi vain yhden henkilön muokkausta varten?

In GitLab by @vesal on Jul 9, 2019, 14:47

Kopioin tuohon ryhmävastaamiseen liittyvät asiat omaan korttiinsa #1436.

Nimenomaan tableFormilla voisikin olla kätevä syöttää tietoja usealle käyttäjälle.

In GitLab by @vesal on Jul 9, 2019, 14:57

Nythän oli edistynyt hyvin. Tuossa

https://timdevs01-1.it.jyu.fi/teacher/users/lehtinen-simo/50fields

tai

https://timdevs01-1.it.jyu.fi/teacher/users/lehtinen-simo/50fields_inline

en löydä heti ainakaan toiminnallisia virheitä ja käytettävyys on jo kertaluokkaa eri tasoa kuin aikaisemmin. Kenttiä ylitettäessä hakee vastauksen käyttäjiä. Liikennettähän tuosta tulee, mutta haittaako käytännössä?

In GitLab by @sijualle on Jul 9, 2019, 15:07

Kenttiä ylitettäessä hakee vastauksen käyttäjiä.

Tuon otin itse asiassa jo eilen yöllä pois mutta jäi pullaamatta tuonne. Nyt menee POSTilla nuo answerpyynnöt

In GitLab by @vesal on Jul 9, 2019, 17:02

Jos kentälle ei näytetä answerbrowseria, niin tarviikos muita vastauksia kuin viimeisen. Jos paljon muutellaan, niin tuosta voi tulla paljon tavaraa. Eli se voisi olla sen hakureitin optiona että kaikki vai vain viimeinen (vai viimeinen sallittu?).

Sitten vastauksessa menee paljon tilaa tuon käyttäjätiedon kuljettamiseen. periaattessa sellaisista vastauksista, joissa ons ama käyttäjä, voisi jättää tuon vastaajan pois ja toimittaa sen vaan yhtenä tietueena. Tosin se tekee (kai???) lisää hommia palvelimen päässä ja viekö se kauemmin kuin tuo datan lähettäminen sellaisenaan? Eli tätä eit ässä vaiheessa kannata optimoida, mutta voisi kirjoittaa johonkin ylös (vaikka uusi kortti: mahdollisesti optimoitava).

In GitLab by @vesal on Jul 9, 2019, 19:38

Tässä samassa vasraam syntyisi metodi, jota voisi kutusua esim jsrunnerista kun on laskettu, joka tekisi saman kuin että vaihtaisi käyttäjää listasta, eli virkistäisi näytön. Mutta se pitäisi voida tehdä myös tableFormeille tai ainkain kutsun parametreissä pitäisi voida tuoda muiden kuin näiden automaattisesti virkistyvien nimiä, jotta ne virkistyisivät myös.

In GitLab by @sijualle on Jul 9, 2019, 20:54

Vaihdoin tuohon käyttäjän vaihtoon taas jonkun kokeellisen funktion mikä tekee plugincontrolin get_answersilla queryn joka palauttaa käyttäjän viimeisimmän validin vastauksen taskiin, tosin siinä tulee vielä turhaa laskentaa vastausten määrästä. Mikalla oli vissiin joku tapa vertailla noiden tietokantafunktioiden nopeuksia?

Nyt ei tule turhaan tuota käyttäjätietodataa vastausten kohdalla, tosin en tiedä miten tuo käyttäytyy nyt jos tulee kahden käyttäjän tekemä vastaus.

In GitLab by @vesal on Jul 9, 2019, 23:25

Joo, aika paljon tuosta nyt tulee erroria. Saitko aikaan niitä kahden omistajan vastauksia?

In GitLab by @sijualle on Jul 9, 2019, 23:40

Nyt on errorit korjattu. Sain tehtyä noita kahden omistajan vastauksia ja kokeilin sillä eilen tuota tableFormin/jsrunnerin tallennusta, siihen saisi periaatteessa yhtä riviä muokkaamalla tallentumaan myös edellisen vastauksen käyttäjälistan. Mutta jos siitä ei toistaiseksi tule mitään indikaattoria jo ennen tallentamista niin ei ehkä kannata?

In GitLab by @vesal on Jul 10, 2019, 24:11

Nythän tuo vaihto vaikuttaa sairaan nopeelta.

Kai tuo data useasta vastaajasta kannattaa tuoda sjo se ei oleellisesti hidasta. Ei kais e hirveä homma ole laittaa fieldiin niin, että sen väri on erilainen tms jos on monen vastaajan fieldi.

Muutenkinhan pitäisi tehdä se että filedit muistaa sen värin, joka niille on annettu jsrunnerissa tai tabelFormissa. SItten vaan pitää keksiä miten sellainen monen vastaajan väri näytettään jos on itsel aitettua väriä ja sittent uota monen vastaajan väriä. Vai keksiikö jonkin muun indikaattorin sille vastaajien osoittamiselle. Mun pitää sitten keksiä vielä taoa, millä tablessa saa ruksit jotakin klikatessa niiden kohdalle jotka ovat vastanneet samaan fieldiin kuin mitä klikkaa. Silloin saisi helposti HT:tä merkitessä niin, että jos edellinen merkintä vasemmassa sarakkeessa on multivastaus, niin sitten saisi ruksittua ne, jotka olis siihen vastanneet ja sitten täyttäisi sen sarakkeen jota HT:ta ollaan merkitsemässä ja vastaus menisi ruksituille. Ei tarviiis rukoilla kertoman että ketäs siinä HT ryhmässä olikaan :-)

In GitLab by @vesal on Jul 10, 2019, 24:22

Oikeastaan tablen toolbaria voisi käyttää tuohon. Siellä voisi olla painike: "Ruksi kaikki tähän vastasukeen sidotut". Ja siellä voisi olla myös ruksit: "Syötä yksilöinä kaikille valituille" "Syötä ryhmänä kaikille valituille". Jos tablessa on multivastaus ja ruutuun menee, niin silloin krostettaisiin siihen kuuluvat vastaukset ja tulisi tuo em ruksi näkyviin.

In GitLab by @sijualle on Jul 10, 2019, 01:03

Muutenkinhan pitäisi tehdä se että filedit muistaa sen värin, joka niille on annettu jsrunnerissa tai tabelFormissa

Mitenkähän tuota kannattaisi lähteä toteuttamaan? Laittaa contentin sekaan jotain värimäärityksiä vai oma taulu jossa viite johonkin vastaukseen? Contentiin lisääminen olisi helpompaa, mutta tällä hetkellä nuo fieldithän on nuivia ja valittaa invalid statea jos sinne sisältöön laittaa mitään muuta kuin c:tä.

In GitLab by @vesal on Jul 10, 2019, 01:42

Miksei saa tallentaa muuta kuon c:n. Minusta se olisi loogista että siinä statessa voi olla myös style tms. mutta normaalisti vain c.

In GitLab by @sijualle on Jul 10, 2019, 04:04

Kai tuo data useasta vastaajasta kannattaa tuoda sjo se ei oleellisesti hidasta

Tää saattaa itse asiassa olla hitaampaa kuin pelkkä vastaajien aina lähettäminen tai lähettämättä jättäminen. Tuolla answerissa on määritely "**include if loaded" tuolle users-kohdalle. Jos tarkastaa tuon vastauksessa olevien vastaajien määrän (users_all pituuden) niin se tulee nopealla testailulla aina mukaan siihen answer-objektiin. Laitoin nyt tuonne taas yhden kokeellisen funktion joka manuaalisesti rakentaa objektin johon se users tulee vain jos niitä on >1, ja nyt se taitaa olla vähän hitaampi kuin ennen.

In GitLab by @vesal on Jul 10, 2019, 08:24

eihän tuo pahalta vaikuta jos siinä nyt on kaikki tarvittava tieto. olikohan tuolla multivastauksia, jotka pilasin?

In GitLab by @sijualle on Jul 10, 2019, 12:05

Joo ei se hirveän hidas ole (ainakaan vrt alkutilanteeseen), mutta kuitenkin hieman (jotain kymmeniä millisekunteja) hitaampi mitä se oli ennen viime yön muokkauksia. Laitoin tuonne https://timdevs01-1.it.jyu.fi/teacher/users/lehtinen-simo/50fields kokeeksi jotain multivastauksia. Osaan noita tuli vahingossa, pitää katsoa textfieldistä miksi lähettää vastauksen kun se saa fokuksen.

Miksei saa tallentaa muuta kuon c:n. Minusta se olisi loogista että siinä statessa voi olla myös style tms. mutta normaalisti vain c.

En tiedä, kai sillä datan tiukalla validoinnilla on omat etunsa https://tim.jyu.fi/view/tim/TIMin-kehitys/perehdytykset/2019#pluginien-kehitys Saahan tuon ainakin fieldien osalta takaisin niin että pluginia ei kiinnosta ylimääräiset content-kentät. Tableformilla voi tällä hetkellä kirjoittaa mitä vaan minkä tahansa pluginin mihin vaan content-kenttään, pitäisikö se pitää tuollaisena (eli sillä voi "kaataa" jonkun pluginin vastauksen pluginista jossa on edelleen tiukka validointi) vai tehdä niin että nuo mielivaltaiset contentkentät toimii vain jos kohteena on joku fieldplugin?

In GitLab by @vesal on Jul 10, 2019, 12:24

Voisko sitä ainakin laajentaa että saa olsl c: mutta saa olla esim myös style jne. mitä sitten mieleen tulee. Tosin en ole ihan varma mitä fieldeissä tuo tarkistus auttaa, koskakantaahan kirjoitetaan ja luetaan ohjelmalla eli eihän sinne (ainakaan vielä) saa ihan mitä tahansa kirjoittaa ja vaikak kirjoittaisi, niin kuka sen osaisi näyttää. Lähinnä jsrunneri on se, josta kautta pääsee ehkä vuotamaan jos sen sallitaan kirjoittaa mitä contenttia tahansa. ja toistaiseksi sallisin. Se antaisi mahdollisuuden lisätä erilaisia info yms juttua vastausten liitteeksi.

In GitLab by @vesal on Jul 10, 2019, 17:00

Kun katsoo F12 ja Network että mitä tapahtuu, niin tuossa on kumma tauko mulla 3.5 ja 5.5 sek välillä. Toinen pisempi tauko on noin 1.5-2 sek välillä. Eli tuossa välillä ollaan aika toimettomana. Tosin kaiki ei varmaan oo sun tekosia :-)

In GitLab by @sijualle on Jul 10, 2019, 22:23

Tarkoitatko tuota taukoa ennen tuota multiplugin3/infosfortask -pyyntöä sivun latauksessa? Tuossa userlistControllerissa on joku kuuntelija joka kutsuu tuota käyttäjänvaihtoa ja siitä tulee tuo ensimmäinen multiplugin3-kutsu vaikkei käyttäjää olisi oikeasti vaihdettu. Voin katsoa vielä tarkemmin

In GitLab by @vesal on Jul 10, 2019, 22:36

Joo. Siinä tuntuisi olevan 1.5-2 sek ihan hukassa.

In GitLab by @sijualle on Jul 10, 2019, 23:27

Näköjään tuo käyttäjävalikon lataus aiheuttaa changeUser-kutsun. Siinä sitten silmukassa käydään nuo loaderit läpi ja odotetaan niiden answerBrowsereiden käynnistymistä mistä tulee tuo viive. Nuo answerbrowserit on kyllä hyvä alustaa tuossa ekassa "turhassa" changeuser-kutsussa, muuten ne alustettaisiin siinä kun käyttäjää oikeasti vaihdetaan ekan kerran ja se odotus siirtyisi sinne. Mutta tuostahan voisi kikkailla tuon ekan changeuserin tekemän multiplugin3-pyynnön pois niin tulee yksi turha request vähemmän. Tosin tuo taskInfos-pyyntö täytyy (jos form_modessa fieldit siis edes tarvitsee tuota infoa) vielä tehdä jossain vaiheessa, joko ekan oikean käyttäjänvaihdon aikana tai tuossa missä se nyt tehdään.

In GitLab by @sijualle on Jul 10, 2019, 23:40

Tai näköjään tuo silmukan tekeminen kahtena silmukkana auttaa myös hieman. Nyt siellä on samassa silmukassa

                lo.loadPlugin();
                await lo.abLoad.promise;

mikä tekee siitä hitaan kun ensin käsketään loaderia lataamaan ja sitten odotetaan sen answerbrowserin valmistumista ennen seuraavaa iteraatiota. Tuossa voisi eka käskeä noita loadereita lataamaan ja toisessa silmukassa katsoa että answerBrowserit on valmiita

In GitLab by @vesal on Jul 11, 2019, 24:56

ok

In GitLab by @sijualle on Jul 11, 2019, 16:47

Muutenkinhan pitäisi tehdä se että filedit muistaa sen värin, joka niille on annettu jsrunnerissa tai tabelFormissa

Nyt onnistuu tableFormilta usean contentin tallennus yhteen vastaukseen joten värin tallennuksen toteutus ei ole enää kaukana. Mutta entäs värin lataus tableFormiin? Pitäisikö get_fields_and_users:in palauttaa neljäs parametri johon se lukee noita contentissa olevia "styles"-kentän alla olevia arvoja?

In GitLab by @vesal on Jul 11, 2019, 16:58

Paljonkohan tulee mergeämistä kun olen aika raalla kädellä käsitellyt tuota timTablea... En ole vielä puskenut noita. Siellä oli (ja on vieläkin) paljon monen solut käsittelyyn liittyvää ongelmaa. Olen muutellut niitä niin, että viedään tallennuksessa palvelimelle lista muuttuneiden solujen sijainneista ja uusista arvoista.

Tätä ajettelin vielä soveltaa tableFormiin niin, että sille viedään sama lista ja sen mukaan mitä on valittu (talelnus yksittäin/ryhmälle) tableForm voi tallentaa nuo eri tavalla.

Katsoppas miten värit nykyisin tallentuvat datablockiin. Taskissa ne eivät taida tallenua (???). Mutta kais samalla idealla ne voisivat tallentua ja tulla kannasta.

Joko se selailupuoli olisi valmis mergettäväksi?

In GitLab by @vesal on Jul 11, 2019, 17:09

Nyt puskin tuon mun tän hetkisen tilanteen. Sä voisit mergetä sen sun nykyiseen koodiin niin ei oltaisi niin kaukana. Erityisesti jos tuon selailun uskaltaisi laittaa tuotantoon kokeiltavaksi. Tosin jos se ei riko vanhoja plugineja, niin uudethan eivät vielä ole kellään käytössä. Toimiiko muuten myös numericfieldille?

In GitLab by @sijualle on Jul 11, 2019, 17:11

Ei kai tuossa mergessä pitäisi konflikteja tulla, mergesin vähän väliä masteria t-t:seen, viimeksi hetki sitten. Muokkasin viime viikolla sitä tableFormia niin että timtable kertoo aina solun muokkaantumisesta tableFormille ja tableForm lähettää tallennettaessa vain ne solut joista on tullut muokkaustieto. Vaikuttaakohan nuo muutokset tuohon?

Jos tuo viimeisin (palvelinpuolella ehkä piirun verran hitaampi kun pitää katsoa vastaajien määrä, mutta datassa kulkee käyttäjätieto vain jos useampi vastaaja) on hyvä niin sitten se on dokumentaatiota ja nimeämistä vaille valmis.

In GitLab by @sijualle on Jul 11, 2019, 17:14

Nyt puskin tuon mun tän hetkisen tilanteen. Sä voisit mergetä sen sun nykyiseen koodiin niin ei oltaisi niin kaukana. Erityisesti jos tuon selailun uskaltaisi laittaa tuotantoon kokeiltavaksi. Tosin jos se ei riko vanhoja plugineja, niin uudethan eivät vielä ole kellään käytössä. Toimiiko muuten myös numericfieldille?

Mergeän vielä kerran. Poistin ne niputetut staterequestit, eli kaikki pluginit toimii vanhalla tyylillä jos ne ei ilmoita tukevansa setAnsweria tai form_mode ei ole päällä, eli ei pitäisi rikkoa vanhoja plugineita.

Ei toimi vielä numericfieldille

In GitLab by @vesal on Jul 11, 2019, 17:32

Ei toimi vielä numericfieldille

Laitako numericfieldin toimimaan kun kaikki tuotannon esimerkit on toistaiseksi numericfieldeille.

On järkevämpi kokeilla sitten.

In GitLab by @sijualle on Jul 11, 2019, 18:14

Nyt toimii numericfieldeille

https://timdevs01-1.it.jyu.fi/teacher/users/lehtinen-simo/50numbers

In GitLab by @vesal on Jul 11, 2019, 18:43

Nyt toimii numericfieldeille

https://timdevs01-1.it.jyu.fi/teacher/users/lehtinen-simo/50numbers

Nyt mää tupelsin jotakin noissa mergeissä :-( Ei löydy multiplugin3 reittiä...

In GitLab by @vesal on Jul 11, 2019, 19:10

Tuo vaihtohan on mielyttävän nopea, mutta tuossa alussa on jotakin hämärää. Vertaa:

https://timdevs01-1.it.jyu.fi/teacher/users/lehtinen-simo/1refrences

https://timdevs01-1.it.jyu.fi/teacher/users/lehtinen-simo/50refrences

kun katsoo Networkkiä, niin tuossa jälimmäisessä menee mulla kotona 5 sek asti ja on paljon noita toimettomia hetkiä. Ei oikein uskoisi että 50 kentän jakaminen tällä koneteholla veisi noita taukojen kokoisia palasia.

In GitLab by @sijualle on Jul 11, 2019, 20:03

Nyt mää tupelsin jotakin noissa mergeissä :-( Ei löydy multiplugin3 reittiä...

Se on nykyään tuo userAnswersForTasks. Multiplugin3 oli ns. "kolmas kokeilu"

Networkkiä, niin tuossa jälimmäisessä menee mulla kotona 5 sek asti ja on paljon noita toimettomia hetkiä.

Koitan katsoa mikä hidastaa, veikkaan että liittyy myös noihin await-hommiin.

In GitLab by @vesal on Jul 11, 2019, 20:04

En tiedä onko nyt kunnossa. Ainakaan ei ole käännösvirheitä eikä muita punaisia ja näyttäisi toimivan sen jälkeen kun sammutin kaikki, buildasin TS:ät ja ./up.sh

In GitLab by @vesal on Jul 11, 2019, 20:24

Nyt on koodi tuotannossa. Voi vähän kokeilla että kaikki toimii kuten tarkoitettu.

In GitLab by @vesal on Jul 11, 2019, 21:45

Aika hassua. Tuolla:

https://tim.jyu.fi/teacher/users/vesal/koe/lomakkeet/50fieldsinline

mulla on vain yksi kenttä täytettynä ja mun osalta haku kestää sellaistet 750 ms kun muilta se kestää n 200 ms. Toki mulla varmaan on vastauksia enemmän kuin muilla, mutta aika paljon silti eroa.

Nyt kun täytin nuo kentät, niin Aku Ankka: 320 ms, Vesa 840 ms.

Siis puhutaan pelkästä userAnswersForTask. ELi tuo on osin ymmärrettävää että aika kasvaa kun kenttien määrä kasvaa, mutta miksi se riippuu vastaajan muiden vastausten määrästä?

In GitLab by @vesal on Jul 11, 2019, 21:49

https://tim.jyu.fi/teacher/users/vesal/koe/lomakkeet/50fieldsinline

Vaikuttaisi että laskennan jälkeen browseaminen lakkaa toimimasta? Lisäsin kenttien määrän 250 ja tuo rupeaa olemaan käytettävyyden rajoilla. Vesa: 1.6 s, muut n. 1 sek.

Korjaus: Selaaminen lakkaa toimimasta jos muokkaa dokumenttia. Ainakin sen fileds-lohkon kohdalta. Joo ja nähtävästi vain sen kohdalta muokkaaminen lopettaa laskennan. Nähtävästi tulee päällekkäisiä rekisteröitymisiä fieldeiltä. Pitäisikö tehdä niin, että jos samalla nimellä tulee uusi rekisteröityminen, niin se viskaa vanhan pois. Jos oikeasti haluaa samaa kenttää käyttää kaksi kertaa samassa dokussa, niin pitäisi antaa joku lisämääre joka erottaa.

In GitLab by @vesal on Jul 11, 2019, 22:13

Nyt tuossa:

https://tim.jyu.fi/teacher/users/vesal/koe/lomakkeet/50fieldsinline?fields=3

voi nopeasta vaihdella tuota kenttämäärää tuolla urlilla 0-250 välillä.

Vesa

In GitLab by @vesal on Jul 11, 2019, 23:42

En saanut (meni aikaa tuon TimCan kanssa) enää sitä TimTablen savea muutettu niin, että se kutsuisi sitä saveCallBackiä vastaavasti kuin kutsutaan /timTable/saveMultiCell

Eli tuolla timTable.ts 1015 ascyn saveCells riviltä 1027 alkaen täytetään ensin lista talennettavista ja niiden koordinaateista ja tämä lista annettaan tallennettavaksi. Nyt tuossa 1021 rivillä kutsutaan calbackiä jokaiselle solulle erikseen ja silloin sillä callbackillä ei ole mahdolista tietää että nämä pitäiti laittaa yhdelle ryhmälle. Ja sittenhän tuohon liittyy vielä se, että jos valittu alue on enemmän kuin yksi sarake, niin callcakin pitäisi option perustella tallentaa jokainen sarake yhtenä ryhmänä tai sitten kaikki solut erikseen. Tuossa on periaattessa mahdollista että samankin sarakkeen eri soluilla olisi eri arvot jolloin niitä ei tietysti voi tallentaa ryhmänä.

Tällä hetekllä tuollaista tilannetta ei tule, mutta periaattessa se olisi mahdollista.

Sitäkään en vielä tehnyt että jos ruksii rivejä, niin se tallentaisi toolbarissa (vielä olemattoman) olevan ruksin perusteella kaikki ruksittuihin (ja taas toisen siellä vielä olemattoman ruksin perusteella joko henkilökohtaisesti tai ryhmänä).

In GitLab by @sijualle on Jul 12, 2019, 01:28

Tuossa on joku taikanumero 38. Jos laittaa fieldien määräksi 36, eli pyytää 190167.fields + d-kentät jolloin tulee 37 taskin request niin sinun kohdalla tulee vastaus jopa nopeammin kuin muilla. Mutta heti kun tulee >=38 taskia niin se pyyntö menee yli 800ms. Saiskohan tätä tietokantapyyntöä jaettua osiin samalla lailla kuin siinä get_fields_and_users:issa?

In GitLab by @sijualle on Jul 12, 2019, 02:11

Selaaminen lakkaa toimimasta jos muokkaa dokumenttia.

Jostain syystä pluginloadereiden abLoader-viitteet katoaa kun dokumenttia muokkaa. Sitten käyttäjää vaihtaessa ne pluginloaderit käsketään lataamaan itsensä kuten aina, mutta tällä kertaa niillä on tuo this.compiled jo valmiiksi true ja ne ei lataa uusia abLoadereita. Ja koska tuossa käyttäjänvaihdossa on tuo await niiden pluginloadereiden abLoadereille se käyttäjänvaihto jää jumiin. Pitäisi keksiä mikä saa nuo pluginloadereiden abLoader-viitteet katoamaan. Tai sitten editorin sulkemisen jälkeen viewctrlilla voisi olla joku tieto että käytiin editorissa ja käyttäjänvaihdossa sanoa noille pluginLoadereille että lataavat ne abLoaderit siitä compiled-flagista riippumatta

In GitLab by @sijualle on Jul 12, 2019, 04:13

Tai näköjään se yrittää (?) käynnistää sitä abLoaderia muttei jostain syystä onnistu. Sain sen toimimaan kun hain this.abseista tuon abLoaderin ja pistin lo.abLoad.resolve(haettu abloader), mutta tuota ei vissiin kannata tehdä joka käyttäjänvaihdolla. Vielä kun keksii jonkun järkevän iffin tuohon väliin jolla saa tarkistettua tarvitseeko resolvea niin sit toimii

In GitLab by @sijualle on Jul 12, 2019, 13:21

Noiden fieldien "followid"-attribuutista joutuu muuten varmaan luopumaan kokonaan, sillä nyt noita kenttiä joita vaihdetaan etsitään sieltä rajapinnasta answerbrowserin taskID:n mukaan. Jos niillä on followid ja ne rekisteröityy jollain tuntemattomalla tunnisteella niin varmaan hajoaa.

In GitLab by @vesal on Jul 12, 2019, 13:28

Kukas niitä käyttää? Alunperin mää taisin tehdä ne ImageX ja video-pluginien väliseen kommunikointiin.

In GitLab by @sijualle on Jul 12, 2019, 13:40

Fieldeissä niitä käytettiin tuon multisaven kanssa, ajatuksena oli että voi antaa kivempia tunnisteita noille tallennettaville fieldeille ja multisavessa sitten listata nuo. Nyt joutuu multisavelle listaamaan tallennettavien taskid:t joka ajaa saman asian.

Tuossa olisi ollut itse asiassa parempi jos usealle kentälle olisi voinut antaa samoja followid-arvoja ja rekisteröityminen olisi kerännyt joka tunnisteen alle listaa eikä yksittäistä controlleria. Sitten multisavessa olisi riittänyt kirjoittaa että tallenna kaikki joiden tunniste on "demot", ilman mitään regexpejä. Nyt ne followid-kentät rekisteröityisivät toistensa päälle jos olis sama id.

In GitLab by @vesal on Jul 12, 2019, 13:46

Tuossa olisi ollut itse asiassa parempi jos usealle kentälle olisi voinut antaa samoja followid-arvoja ja rekisteröityminen olisi kerännyt joka tunnisteen alle listaa eikä yksittäistä controlleria. Sitten multisavessa olisi riittänyt kirjoittaa että

Noilla timcanissa on type, joka liimaa noita yhteen:

https://tim.jyu.fi/view/kurssit/tie/proj/2019/timcan/kayttoohjeet/user-manual-for-drag-plugin#multiple-types

Eli varmaan tuo ajaisi tuota asiaa jos haluaisi. Jos ajatuksena on niputtaa yhteenkuuluvia samaan kasaan.

TIM-JYU / TIM

Paljon kenttiä sisältävän sivun browseaminen #1420