Open dezhidki opened 7 years ago
In GitLab by @Smibu on Nov 3, 2017, 14:31
@vesal Hetken aikaa ihmettelin tuota, mutta nyt tajusin, että tuo johtuukin noista dokun aliaksista.
F5 toimii, koska silloin dokun polku on yksikäsitteinen ja kannasta löytyy oikea alias (kunhan selaimen URLissa on polku eikä pelkkä id). Mutta sitten noissa preview- ja tallennusreiteissä doku identifioidaan vain sen id:llä, minkä takia kannasta tulee vain jokin alias ja jos se on väärä, niin preambletkin menevät väärin (elleivät kaikki aliakset ole samassa hakemistossa).
Tuon ratkaisemiseksi dokun aliaksista jokin pitäisi varmaankin merkata "pääaliakseksi", jonka perusteella haetaan preamblet.
Jos pääaliaksen tekee, niin luultavasti sivualiakset ja id kannattaa redirectata pääaliakseen. Eli selaimen URLissa näkyisi aina pääalias.
TIMissä näkyy olevan 106 dokua, joilla on enemmän kuin 1 alias.
In GitLab by @Smibu on Nov 3, 2017, 14:38
@Smibu Entäs miten sitten toimisi aliakset? Mulla oli vähän haave että jos dokulle on alias toisesa hierarkiassa, niin silloin premablet tulevat sieltä, jolloin samoja dokuja voisi käyttää ihan erinäköisillä "koristeilla".
Esim nyt on yksi kusrri jossakin TIEP1000 tms ja sitten saman olisi takoitus olla joskus myös tekoälyn alla ja silloin sillä voisi olla oma ulkoasunsa.
ELi onko mulla nyt ongelma myös Ohj1 monisteen kanssa kun suurin osa siihen johtavosta linkestä on view/1 kun se on ollut niin helppo kirjoittaa? – Vesa Lappalainen
In GitLab by @Smibu on Nov 3, 2017, 15:55
Entäs miten sitten toimisi aliakset? Mulla oli vähän haave että jos dokulle on alias toisesa hierarkiassa, niin silloin premablet tulevat sieltä, jolloin samoja dokuja voisi käyttää ihan erinäköisillä "koristeilla".
Ok, silloin tuo pääaliasjuttu ei toimisi.
Itse oon mieltänyt nuo aliakset aina niin, että ne ovat vain eri polkuja tismalleen samalle dokulle.
Jos preamblet pitäisi ottaa vastaavasta hierarkiasta, niin entä muut templatet tai velpit?
Jos preamblessa määritellään makroja, niin pitäisikö makrot kopioida siihen toiseen hierarkiaan (jotta doku näkyy oikein)?
Minusta tuolle koristelulle kannattaisi keksiä jokin toinen mekanismi. En oikein osaa sanoa, mikä sen kannattaisi olla, koska pitäisi tietää yleisimmät käyttötapaukset tuollaiselle "koristelulle".
Esim nyt on yksi kusrri jossakin TIEP1000 tms ja sitten saman olisi takoitus olla joskus myös tekoälyn alla ja silloin sillä voisi olla oma ulkoasunsa.
Eli tällöin olisi vain erilainen CSS?
ELi onko mulla nyt ongelma myös Ohj1 monisteen kanssa kun suurin osa siihen johtavosta linkestä on view/1 kun se on ollut niin helppo kirjoittaa?
Jos sillä on enemmän kuin 1 alias, niin joo.
Jos nuo linkit on TIMin sisällä, niin ne lienee ainakin helppo päivittää skriptillä.
In GitLab by @Smibu on Nov 3, 2017, 18:10
@Smibu Miksei toimisi jos on niin että jos URlissa on hakmeisto, käytetään sen hakemiston premamblea / Templateja. Jos URLissa on id, käyteään ensimmäistä aliasta.
Vai jopa niin, että jos URLissa on 1. alias, niin käyteään sitä. Jos URLissa on muu alias, niin haetaan ensin 1. aliaksen premable ja sitten sen URLissa olevan preamblet. Silloin asetukset tulisivat sieltä pääpreamblesta (jos niitä ei muuteta) ja esim. css:ää voisi muuttaa niisä muissa aliaksissa. – Vesa Lappalainen
In GitLab by @Smibu on Nov 3, 2017, 19:34
Miksei toimisi jos on niin että jos URlissa on hakmeisto, käytetään sen hakemiston premamblea / Templateja. Jos URLissa on id, käyteään ensimmäistä aliasta.
Joo siis meinasin vaan, että se pelkkä pääaliasjuttu, jonka ekassa kommentissa kuvailin, ei riittäisi niihin "koristeluihin".
Vai jopa niin, että jos URLissa on 1. alias, niin käyteään sitä. Jos URLissa on muu alias, niin haetaan ensin 1. aliaksen premable ja sitten sen URLissa olevan preamblet. Silloin asetukset tulisivat sieltä pääpreamblesta (jos niitä ei muuteta) ja esim. css:ää voisi muuttaa niisä muissa aliaksissa.
Juu, tuo toki kuulostaa loogiselta. Eikä vaatisi sitä, että pitäisi kopsata preambleja sinne toisen aliaksen hierarkiaan.
Eli ihan joka tapauksessa aliaksista pitää pystyä määrittämään pääalias, koska muuten pelkän dokun id:n perusteella ei ole selvää, mikä alias halutaan. Se ei ole iso homma.
Mutta sitten tuo, että dokun ulkoasu (preamblet ja asetukset) riippuisivat polusta on jokseenkin isompi juttu kuin miltä se kenties kuulostaa aluksi. Vaatii ainakin:
No nyt kun kirjoitin tuon auki, niin ei se välttämättä valtava homma ole. Jos nuo 2 ovat ainoita :)
Templatet eivät vissiin ole relevantteja tässä yhteydessä, koska ne koskevat vain tyhjiä uusia dokuja. Ei kukaan dokun luotuaan mene heti lisäämään sille aliaksia ja mene editoimaan sitä muuhun paikkaan.
Velpeissä kannattanee käyttää aina pääaliasta (?). Silloin ei tarviisi niihin liittyviä AJAX-reittejä muuttaa.
In GitLab by @Smibu on Nov 3, 2017, 20:30
@Smibu Jättäisin varauksen tuohon että joskus Velpit voisivat riippua polusta. Toki kun eri aliasten käyttötapauksia ei ole vielä paljoa, niin tuolla ei ole kiire. Ja perustemplatesta minusta havintosi oli oikea. – Vesa Lappalainen
In GitLab by @vesal on Dec 5, 2017, 10:54
Olisiko aliasten ja preamblen kohdalla seuraava mahdollista:
Polku määrää mitä preambleja käytetään
1) Jos tullaan osoitteella view/1 niin käytetään "polkuna" 1. aliaksen polkua
2) Jos tullaan jollakin alias-URLilla, niin sen aliaksen polku määrää preamblen
Käyttötapauksia:
1) Ohj1 moniste on sijoitettu sekä kurssit/.../ohj1/... että aalto/... alle Jos aalto-hakemistossa on omat preamblet, niin niitä ei ohj1
2) Jos on dokukmentti jolla on aliakset .../2017s ja .../2018k niin preambleja etsitään vastaavasti noista kansioista (ja toki ylempää)
Ja sama kai pitäisi olla templatejen (mitä kaikkea sieltä tulee, eikös templatet ole uusien dokumenttien mallipohjia? Uusia dokuja luodessa pitää olla hakemistossa ja silloinhan tätä ongelmaa ei ole.
Velppien kanssa on tietysti ongelma että liittyvätkö velpit dokumenttiin vaiko hierarkiaan. Ja pidemmällä tähtäimellä varmaan pitäisi voida velppilistassa valita kumpiako vaiko molempia haetaan ja kumpaanko tallennetaan.
In GitLab by @Smibu on Dec 5, 2017, 11:21
Tuo siis kannattaa toteuttaa kahdessa vaiheessa:
In GitLab by @vesal on Dec 5, 2017, 13:47
onko se hyvä jos pääaliaksesta otetaan preamble? silloin tuo eri hakemistoista tuleva ulkoasujuttu voisi kärsiä. Tai toki jos kaikki on overridettävää, niin silloin ok.
In GitLab by @ajlakanen on Dec 5, 2017, 13:57
Jos dokumentille tehdään selkeästi erilaisia (kansiorakenne-mielessä kaukana toisistaan olevia) aliaksia / urleja, niin kyllä minusta olisi hyvä dokumentin tekijän perspektiivistä että hänen ei tarvisi murehtia siitä että näyttääkö ja toimiiko dokumentti varmasti samalla tavalla kaikilla urleilla. Tai että onko jonkin toisen kansion käyttäjällä pääsy sellaiseen preambleen joka voi mahdollisesti myöhemmässä vaiheessa hajottaa dokumentin.
Voisko tuossa @vesal mainitsemassa käyttötapaus nro 1:ssä käyttää lainauksia ennemminkin kuin aliasta?
In GitLab by @vesal on Dec 5, 2017, 14:05
en käyttäisi tuossa kt1:ssä lainauksia koska se ei anna kaksisuuntaista muokkausta. eli tavallaan alias on koko dokumentin 2 suuntainen lainaus.
mutta mikä oli ongelma?
In GitLab by @ajlakanen on Dec 5, 2017, 15:15
Okei, no silloin sen toiminnon nimi varmaan olisi jotakin tuon tapaista (koko dokumentin kaksisuuntainen lainaus).
Mutta alias / URL alias minusta sanana on sitä että pitkästä osoitteesta tehdään käyttäjälle helpompi kirjoittaa, sisältö ei muutu. Tällöin dokumentin tekijän ei tarvisi murehtia siitä että mitä tapahtuu kun annan dokumentille tietyn aliaksen, tai että mikä alias on sallittu ja mikä ei.
Periaatteessa uudelleenohjauskin voisi riittää tällaisessa yksinkertaisessa tapauksessa, vastaavasti kuin esim r.jyu.fi.
In GitLab by @vesal on Dec 6, 2017, 14:28
Okei, no silloin sen toiminnon nimi varmaan olisi jotakin tuon tapaista (koko dokumentin kaksisuuntainen lainaus).
no ei tuokaan kovin hyvä nimi ole.
Jos "From what addresses the document is possible to reach"? Tai jotakin selaista lyhennettynä. Ja ehkä huomatus siitä, että ulkoasu voi olla erilainen eri kautta katsottuna.
Entä joku "Other visibilies"? siinäkin on se väärin, että sen ei ole pakko olla näkyvissä.
Ja tosiaan nykyisellä ohj1-rakenteella ei voisi ottaa sitä oletus-preambleakaan käyttöön, sillä ohj1:ssä se sisältään mm. sen navigonnin, joka varmasti pitäisi olla erilainen Aalto-yliopiston versiossa.
Mutta alias / URL alias minusta sanana on sitä että pitkästä osoitteesta tehdään käyttäjälle helpompi kirjoittaa, sisältö ei muutu. Tällöin dokumentin tekijän ei tarvisi murehtia siitä että mitä tapahtuu kun annan dokumentille tietyn aliaksen, tai että mikä alias on sallittu ja mikä ei.
Pitäisikö tuota aliasta olla tuossa siis kahta eri tyyppiä? Sellaista jossa sisällön on tarkoituskin näkyä eri hierarkiassa ja sellaista, jossa on kyse oikeasti vain uudelleen ohjauksesta. Jälkimmäiseen olen käyttänyt tuota r.jyu.fi/ohj1
Voisihan TIMissä olle erikseen reitti
tim.jyu.fi/r/ohj1
joka uudelleensuuntaa valittuun osoitteessen. Tuolle voisi olla managessa oma linkki josta tuo lisätään, koska silloin on järkevää sallia muutkin osoitteet kuin view. Esim mun r.jyu.fi/ohj1 menee nyt tenttiin ja luentojen aikana luentojen lecture view -osoitteeseen. Ja samalla toki herää kysymys, että miksei silloin saa redirectata myös TIMin ulkopuolellekin? r.jyu.fi on kielletty jyu.fi ulkopuolella redirectaaminen ja sekin on hieman harmillista välillä.
Valitettavasti tuokin osoite on kännykällä aika paljon hankalampi kirjoittaa kuin r.jyu.fi/ohj1 (pidempi ja useampi kauttaviiva). En tiedä saisiko helposti
r.tim.jyu.fi/ohj1
joka olisi hmpin helpompi kirjoittaa kännykällä. Ihanne olisi tietty jos saisi
t.jyu.fi/ohj1
Mutta siis siihen asti kun tuollaisen saa tehtyä, niin mulla r.jyu,fi hoitaa aika hyvin hommansa. Pitää muuten muistaa vapauttaa r.jyu.fi/ohj1 AJ:lle tai siten AJ:n pitää kertoa mihin se laitetaan.
Vesa
In GitLab by @Smibu on Oct 30, 2017, 12:33
https://tim.jyu.fi/view/kurssit/tie/ohj1/materiaali/Kaantaminen
Tuolla kun muokkaan otsikoita (kun autonumerointi tulee preamblesta), niin numerointi aina häviää. Toki palaa refreshillä.