Artikkelilistauksen sivutus ja pari mutkaa
Blogin rakentaminen näemmä jäänyt vähän tauolle viimeaikoina, joten päätin tehdä edes jotain pientä kehitystä. Artikkeleita on jo toistakymmentä ja kaikki näkyivät etusivulla ja kokonaisina. Perinteisellä sivutuksella saisin etusivua lyhemmäksi. Sivutus ei toimintona ole välttämättä niitä jännittävimpiä, mutta toteutus osoittautui silti vaiheikkaaksi.
Totesin siinä, etten ole tainnut koskaan itse kirjoittaa blogin sivutustoimintoa, vaan aina on cms:ssä ollut valmiina tai edes frameworkissa sivutus-komponentti. “No, puolen tunnin juttu”, ajattelin. Varmistin, että minulla on puolen tunnin työn vaatimat kaksi tuntia aikaa vapaana, ja aloitin työt.
–
Toimintona sivutus on jokseenkin yksinkertainen, ja pystyinkin rakentamaan sen ensin mielessäni melkein kokonaan: dynaamiseksi url-parametriksi sivun numero (tyyliin ?page=2), joka parsitaan kontrollerissa ja jonka avulla lasketaan tietokantahaun offset. Itse sivulla näkyvän valitsimen toteutukseen prev/next -nappuloineen ei ollut niin selkeää ajatusta. Twitter bootstrap tarjoaa visuaalisen komponentin, mutta sen generointi datan perusteella vaatisi hieman kokeilua. Matkaan tuli kuitenkin pari ylimääräistä mutkaa…
Matto lähti alta
Ensimmäinen mutka tuli heti alkuun, kun sivusto ei toiminut alkuunkaan. Koneellani on vain yksi Julia-ympäristö, jota kaikki koodi käyttää. Parissa kuukaudessa suurin osa kirjastoista oli päivittynyt, eikä yhteensopivuus taaksepäin ollut aina säilynyt. Tämä oli toki alusta asti tietoisesti otettu riski, kun käyttää uutta teknologiaa. Julialta puuttuu vielä työkalut projektien erityttämiseen omiin ympäristönsä, jotta yhden projektin päivitys ei rikkoisi toista [Playground.jl sanoo tuovansa Pythonin virtualenv-tyyppisen ratkaisun Juliaan].
Puolisen tuntia meni selvittää mikä oli hajonnut ja miten korjata. Toinen hidaste tapahtui url-parametrien käsittelyssä. Tässä samoin, kirjastokutsujen rajapinta oli muuttunut edellisestä kerrasta.
Staattinen sivu, dynaaminen parametri
Itse toteutuksen detaljeissakin, kuten kontekstin määrittelyssä Mustache-templatelle, oli pientä säätöä, mutta lopulta sivutus näytti toimivan. Voitonriemuisena päivitin blogin tuotantoon. Käytän edelleen staattista generointia, eli lataan sivun wgetillä levylle, ja siirrän rsyncillä palvelimelle. Hyvältä näytti. Vaan ei toiminut. Ei tietenkään toiminut, sillä eihän staattisilla sivuilla voi käyttää dynaamisia url-parametreja. Nolohko huomio tässä vaiheessa.
Ratkaisuna toteutin routerin ilman get-parametreja, käyttäen url-polun osaa parametrina. Eli kysymysmerkki kauttaviivaksi. Ja tähän vielä bonuksena myös route-parametrien käsittelyn rajapinta oli ehtinyt muuttua edelliskerrasta…
Toimisko nyt?
Content-type: application/octet-stream
Ei. Klikatessani staattisen version sivuttimen linkkiä, kysyykin selain minulta mihin haluan tallentaa tiedoston. Väärä sisältötyyppi. Tämä korjaantui onneksi yhdellä rivillä (default_type text/html;) Nginx-konfiguraatioon. [Myöhemmin tajusin, että asia olisi korjautunut myös lisäämällä url:n perään kauttaviiva, jolloin wget olisi luonutkin päätteettömän tiedoston sijaan uuden hakemiston ja sinne index.html-tiedoston.]
Huh. Nyt näyttäisi toimivan. Itse sivuttaminen jäi tässä työssä sivuosaan, mutta kyllä siitäkin silti jotain opin.
Odotin aluksi joutuvani tekemään monimutkaisemman härvelin, koska sovelluskehysten sivutuskomponentit saattavat olla monimutkaisia. Ne yrittävät sivuttaa mitä tahansa asioita missä tahansa tilanteessa. Ja koodarin pitää pystyä pääsemään väliin sivuttimen luontiin sekä tiedonhaku- että html-tulostusvaiheessa. Olen käyttänyt helposti pari tuntia myös niiden käytön ja kustomoinnin opetteluun. Saman ajan käyttäminen sivutuspyörän uudestaan keksimiseen oli ainakin oppimisen kannalta mielekkäämpi kokemus.