Uutiset:

Ilmoitustaulu mahdollisten ongelmien varalta (wikimedia.org / Etherpad)

Sähköpostia ylläpidolle: kantapaikanherra (at) gmail.com

Main Menu

Ohjelmointi

Aloittaja Juha, helmikuu 03, 2019, 10:01:17

« edellinen - seuraava »

0 Jäsenet ja 3 Vieraat katselee tätä aihetta.

-:)lauri

^
selvisi että uudistus toteutetaan microservice-periaatteella. Jos olen oikein ymmärtänyt, tämä tarkoittaa, että järjestelmän ominaisuudet toteutetaan kukin itsenäisinä järjestelminä tarkoittaen, että nuo ominaisuudet voidaan toteuttaa millä kielellä tahansa.

Hiukka jo mietinkin, että mitä aikovat tehdä tiimin PHP-koodareille jos siirtyvät Pyyttoniin. Todennäköisesti eivät tee mitään. Toteuttavat kaiketi ohjelman, joka kokoaa ominaisuudet yhdeksi ohjelmaksi Pyyttonilla ja sen jälkeen kukin ominaisuus voidaan ohjelmoida kielellä, joka on olemassa oleville ohjelmoijille tutuin. Eli tyyliin että ominaisuus voidaan ohjelmoida Pyyttonin sijaan esimerkiksi PHP:lla.

Tosin en kyllä otsikkotasoa kummallisemmin tutustunut suunnitelmiin, että en osaa sanoa tarkoittaako Pyyttonin mainitseminen samalla myös sitä, että PHP-koodaritkin siirtyvät pikkuhiljaa kukin Pyyttoniin, mutta pelkästään tieto, että toteutustapa on microservice, sallii ominaisuuksille minkä kielen tahansa, kun pääohjelmaa ei varsinaisesti kiinnosta, miten ja millä kielellä ominaisuudet on toteutettu, kunhan niiden avaamat käyttöliittymät pääohjelmalle ovat pääohjelman tiedossa.
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.

-:)lauri

Pyyttonin opiskelussa ollaan edetty decoraattoreihin tai siis juuri sain käytyä dekoraattori-osion läpi. Decoraattorit olisivat mahdollisia myös javascriptissä. Ihan ekaa kertaa elämässäni tutustuin tässä konseptiin. Nimi on ennestään tuttu, mutta mitään katkua ei ole ollut, miten ne tarkalleen ottaen toimivat. Pyyttonikurssilla konsepti käytiin juuri seikkaperäisesti läpi.

Olen tähän asti opetellut ohjelmoimaan ilman niitä, mutta ottaen huomioon, että varsin usein tulee tehtyä oma funktionsa, joka ohjaa switch-rakenteella ohjelman avainsanan perusteella oikeaan funktioon, olisi mulla ainakin noissa tilanteissa juuri decoraattorin mentävä aukko. Tähän asti on pitänyt aina etsiä ja päivittää erikseen tuota switch-funktiota, jos jossain kohtaa ohjelmaa tarvitsee uuden ohjauksen. Dekoraattori-periaatteella rakennettu funktio voidaan kuitenkin rakentaa pyyttonissa ja javascriptissa niin, että siihen voi tallentaa aina uuden ohjauksen siinä kohtaa koodia missä uusi ohjaus tulee tarpeeseen ilman, että joutuisi decoraattori-funktiota erikseen päivittää. Pitääpä tsekata miten decoraattorit toteutetaan php:n puolella. En siis tiedä sitäkään taipuuko kenties php decoraattoreihin.
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.

-:)lauri

Onko 343 euroa vuoden opiskeluoikeudesta Courseran verkkokursseille hintansa väärti?

Opetuksesta näyttäisi vastaavan yliopistot eri puolilla maailmaa, joten vaikka opettajien ammattitaidosta homma ei kiinni jäisikään, en ole ihan varma osaavatko he painottaa kursseillaan samoja asioita kuin ohjelmoinnin ammattilaiset yksityisellä sektorilla. Tieteellisissä aiheissa voisin olettaa yliopistoilta löytyvän cutting edge -osaamista ohjelmointiin, mutta miten on yksityisen sektorin sovelluskehityksen osaamisen kanssa. En ole yliopistolla opiskellut, mutta ammattikouluissa kylläkin ja niissä kursseilla läpikäydyt yksityisen sektorin kuvitteelliset projektit ovat olleet niin luokattoman heikkolaatuisia, että ei ole ainakaan minulle mikään yllätys, että it-alalla on jatkuvasti huutava pula osaavista ohjelmoijista, vaikka kouluista valmistuu satoja ohjelmoijaspettarilla varustettuja janttereita joka vuosi.

Minun rima on muutenkin vedetty juuri nyt korkealle. Tämä Udemyn ensimmäinen osa neliosaisesta pyyttonin deep dive -kursssista, jota olen käynyt läpi, on sen verran laadukasta tavaraa, että en ole yhtä laadukkaaseen kurssiin vielä koskaan elämässäni törmännyt. Toki tämä on vain minun subjektiivinen arvioni. Jos pyyttoni on hallussa, tämä kurssi voi tuntua pitkästyttävältä. Mutta minun kohdallani kaikki palaset ovat loksahtaneet yllättävän hyvin kohdalleen. Okei, ehkä tässä hiukka liikaa painotetaan itsestäänselvyyksiä, mutta sallittaneen kurssin vetäjälle hieman taiteellisia vapauksia selittää itsestään selvää logiikkaa auki, sillä kaikki ihmiset eivät ehkä täysin hahmota modaalilogiikkaa. Kurssin vetäjä on Fred Baptiste, jolla on ammatillista osaamista CNN:n insinöörinä aivan mediamaailman it-osaamisen huipulta ja ainakin minun on helppo nähdä soveltavani näitä oppeja suoraan käyttämilläni kielillä työprojekteissani.
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.

-:)lauri

Ostin juuri reilulla 200 eurolla udemykursseja (13 kpl). Coursera tuskin tulee ihan hetkeen ajankohtaiseksi :D
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.

-:)lauri

Pari viikkoa sitten kun asensin Visual Codeen jonkun pyyttonin lisäpalikan, se ehdotti, että asentaisin pyyttonin koneeseen, vaikka mulla oli jo silloin pyyttoni koneella. En tiedä mitä tässä parin viikon aikana on tapahtunut, mutta nyt kun avasin Visual Coden ja käynnistin kyseisen lisäpalikan, kaikki pelasi niin kuin pitikin ja saatoin ajaa kirjoittamaani pyyttonia ohjelman terminaalissa. Mahtoikohan mulla jäädä pari viikkoa sitten tuo lisäpalikka käynnistämättä(?), se selittäsi. Harmi kun en osaa käyttää sujuvasti Visual Codea niin tällaiset mystiset ongelmat ovat arkipäivää.
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.

-:)lauri

Tajusin viimein kysyä esimieheltäni, että onko projektissamme mahdollisuutta tallentaa sellaista customoitua logi-tiedosto johonkin paikkaan. Olihan siinä ja nyt sain väsättyä ensimmäisen vedoksen virheloggauksesta. Eli jos ilmenee tilanne, että jossain tietueessa ei ole tarvittavaa tietoa ja ajo pysähtyy sen tietueen osalta, tulee siitä merkintä logiin. Tämä ajo ei olisi niin suuri pulma, jos joku valvoisi sitä, mutta kun se tehdään tausta-ajona, jota kukaan ei valvo. Jos joku tekee pistotarkistuksen kolmannen osapuolen järjestelmään ja meidän järjestelmään ja transaktiot eivät täsmää varastotilanteen kanssa, puuttuvia artikkeleita olisi tai voisi olla työlästä paikantaa. Nyt kun tuosta ajosta jää rekisteriin merkintä jos joku artikkeli ei meidän päästä lähdekään, niin kyseinen artikkeli löytyy ainakin useimmissa tapauksissa suhteellisen näppärästi tuosta logi-tiedostosta.

Pitää tosin vielä logittaa suoritetun tietokantahaun ehdot jos kolmannen osapuolen API palauttaa virheen, niin voimme sitten jälkikäteen ajaa manuaalisesti tietokantahaut ja todeta, missä kohtaa joku tarvittava tieto puuttui tai oli väärää tietotyyppiä.

Olen tätä järjestelmää kehittänyt nyt yli puolivuotta ja olisin kaivannut logitusmahdollisuutta jo aiemmin. Kun on hidas sytytys, pitää tulla toimeen ilman elämää helpottavia tietoja.  :D
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.

-:)lauri

#186
Tuli mieleen tuosta Skepsiksen palstan serverin kuormitusongelmia tuottavasta puurakenteesta, että eikö sitä voisi tehdä niin, että viesti-taulussa olisi kenttä, jossa sen viestin id, johon viesti on vastaus. Näin voisi hakea yhdellä simppelillä lauseella halutun viestiketjun kuten nykyisessä systeemissä, mutta kun hakutuloksessa tulisi myös tieto, mihin viestiin viesti on vastaus, selaimessa voisi rakentaa enemmän tai vähemmän helposti tuon puurakenteen. Tosin tämä edellyttäisi backendistä API-toteutusta, johon selain ottaisi yhteyttä. Nyt backend ilmeisesti rakentaa näkymän valmiiksi ennen kuin se lähtee selaimeen.

Tai kun siellä ilmeisesti jo on tuo tieto mihin viestiin mikäkin viesti on vastaus ehkäpä jokaiseen viestiin pitäisi lisätä viestiketjun ekan viestin id. Tuon kentän arvolla voisi simppelisti hakea kaikki viestit, joissa tuon kentän arvo on sama, ja siinä olisi kaikki kyseisen viestiketjun viestit. Nuo frontendiin ja siellä sitten puutoteutus.

Tai ottaen huomioon, että heillä ilmeisesti on tiedot jo tällä hetkellä molemmista rakenteista (viestiketjun kaikki viestit ja mihin viestiin mikäkin viesti on vastaus), herää kysymys, miten ihmeessä tuo tietokanta on toteutettu jos tuon puurakenteen duunaaminen syö resursseja liikaa.

Vai mikä olikaan se Hipin ehdotus tähän ongelmaan?
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.

Jaska

Viestitaulussa on tietenkin vastatun viestin id ja tieto ketjusta missä viesti sillä hetkellä sijaitsee sekä tieto joka ilmaisee viestien talletusjärjestyksen esim. tallettamisen aikaleimana tai nousevasti annettuina tunnisteina.
Kieli pitkällä odotan yksinkertaista ratkaisuasi. Ongelmaa pohdin Tietokoneketjussa ja jäin odottamaan ratkaisua, joka ei olisi resurssisyöppö. Tästä syystähän Skepsis kertoi poistaneensa vastaushierarkian esittämisen käytöstä.
Tehtävähän on ihan klassinen puun läpikäynti esijärjestyksessä, jolla saadaan vastaushierarkia linearisoitua. Tehtävä tavallisesti ratkaistaan rekursiivisilla funktiokutsuilla tai vastaavalla ei-rekursiivisella pinokäsittelyllä ja se tietenkin löytyy netistä hakukoneella.

Hippi

Eipä ole Hipillä ratkaisua, kun kokemusta on vain yhden tyyppisistä relaatiotietokannoista ja käytöstä. Niissäkin ratkaisu voi olla useamman laatuinen sen mukaan, miten kanta on toteutettu ja onko esim. normalisointi viety miten pitkälle.

Joka tapauksessa ideana on kannan suunnittelun yhteydessä suunnitella myös indeksit, joita enimmäkseen tulisi käytettäväksi. Tuossa foorumitapauksessa olisi kaksi vaihtoehtoista indeksiä – toinen, jolla saadaan "päähaulla" haettu data siihen esim. tämän foorumin esitysjärjestykseen ja toinen, jolla saadaan puujärjestykseen. Lisäksihän tarvitsee ehkä tehdä yksittäiseen viestiin liittyvät lisähaut vähän riippuen siitä, miten viestin data on kantaan sommiteltu. [Omassa duunissani voi lisähakuja tulla moneen kymmeneen, jopa pariin sataan, tauluun asiakastunnisteella sen jälkeen, kun ensin asiakkaat on haettu esiin tarvittavassa järjestyksessä eli kaikki asiakkaaseen liittyvät data ei ole suinkaan yhdessä taulussa]

Käyttäjä ilmoittaa foorumille tullessaan, kumpaako esitysmuotoa kyseisellä käyntikerralla haluaa käyttää. Tuo kai on myös mahdollistaa muuttaa lennostakin käyttöliittymässä. Mutta tämä täppä ilmoittaa, kumpaako indeksiä hakutoiminto käyttää. Ja kuten Jaska jo sanoi, niin kunkin viestin rivillä on tieto siitä, mihin viestiin se on vastaus tai jos se on uusi nollatason viesti, niin tämä puuttuu. Lisäksi indeksissä tulisi olla viestin aikaleima, jotta hakutulos pysyisi loogisessa järjestyksessä ajan mukaan.

Tuossa nyt vähän aamuväsyneenä kirjoitettuna ajatus auki tietämättä ollenkaan millainen on ko. fooruminen kantarakenne.
If you see your glass as half empty, pour it in a smaller glass and stop complaining. ❤️

-:)lauri

#189
Viikonloppu mennyt siinä, että nikkaroinut php:lla mvc-kirjaston nollasta. Sain eilen duunattua kuitenkin myös skriptin, joka tuottaa satunnaisia viestejä, jotka linkittyvät toisiinsa satunnaisiesti ja tietenkin eri järjestyksessä kuin missä järjestyksessä viestit on luotu. Eli vastannee haluttua keskustelupalstatoteutusta. Menin nokkelana tekemään sen javascriptillä. Olisi kantsinut tehdä se php:llä niin konvertointi sql-queryksi ei olisi niin monen stepin takana. Seuraavaksi pitää saada data tietokantaan sekä sen palautus näytölle ja johonkin kohtaan prosessia pitää vielä keksiä se viestin järjestely puuksi ja sitten pääsisi testailemaan tuota serverin kuormittavuutta.

EDIT: Tässä alla poiminta noista lorem ipsum -viesteistä ekan viestiketjun alusta. Eli id-siinä järjestyksessä kun viestit on luotu ja parent_id randomissa järjestyksessä jos kohta kuitenkin valittu jo olemassa olevien id-numeroiden joukosta. Muu sisältö tietueisiin generoituu paria poikkeusta lukuun ottamatta satunnaisesti.
        [
            'id' => 1,
            'parent_id' => null,
            'topic_id' => 1,
            'user_id' => 8,
            'created' => '2020-07-15 05:46:37',
            'modified' => null,
            'user_name' => 'Konsta Kehittäjä',
            'heading' => 'Tempus et hendrerit u',
            'body_text' => 'Ut etiam non arcu duis a at vestibulum quis arcu metus bibendum sagittis amet luctus. Nec sem aliquet lorem massa justo accumsan ultricies commodo a volutpat mollis feugiat aenean. ',
        ],
        [
            'id' => 2,
            'parent_id' => 1,
            'topic_id' => 1,
            'user_id' => 8,
            'created' => '2021-06-13 00:24:50',
            'modified' => null,
            'user_name' => 'Konsta Kehittäjä',
            'heading' => 'Tempus et hendrerit u',
            'body_text' => 'Mauris nunc felis elit nunc vel maecenas habitant dictumst posuere sed mollis volutpat aliquam praesent ac sit suscipit at dignissim nunc fames a. Aliquam tempus pellentesque morbi sit nisi erat nullam justo eu metus diam ut congue scelerisque donec curabitur rhoncus ridiculus ut velit integer massa. Nunc ut posuere sed est amet at at.',
        ],
        [
            'id' => 3,
            'parent_id' => 2,
            'topic_id' => 1,
            'user_id' => 3,
            'created' => '2021-09-29 07:36:07',
            'modified' => null,
            'user_name' => 'Tero Testaaja',
            'heading' => 'Tempus et hendrerit u',
            'body_text' => 'Semper pellentesque ac duis rutrum donec amet diam eros imperdiet eleifend nullam dolor hac tempor fusce proin sed et convallis quam neque urna. Nam amet eros donec tellus vestibulum sollicitudin luctus vitae massa amet dignissim urna quam a turpis aliquam facilisis magna tellus et at vestibulum.',
        ],
        [
            'id' => 4,
            'parent_id' => 2,
            'topic_id' => 1,
            'user_id' => 5,
            'created' => '2020-09-07 23:22:14',
            'modified' => null,
            'user_name' => 'Kaarlo Koodari',
            'heading' => 'Tempus et hendrerit u',
            'body_text' => 'Et facilisis sed curabitur sapien augue luctus tempor purus et lorem. Nibh leo pretium ligula ultrices sem molestie accumsan ornare nunc sit augue euismod tincidunt cras augue justo molestie neque vel turpis sed cras bibendum curabitur vel lacus. Dictumst eget massa porttitor sed ante risus morbi congue. In orci ultrices quis justo phasellus mollis pellentesque nec egestas neque in hac felis id arcu in ultrices ornare velit quis turpis posuere dui. Sit maximus non eget amet nec sollicitudin ultrices elementum neque ut molestie eu ut vestibulum mauris viverra. ',
        ],
        [
            'id' => 5,
            'parent_id' => 1,
            'topic_id' => 1,
            'user_id' => 6,
            'created' => '2021-10-08 12:31:15',
            'modified' => null,
            'user_name' => 'Mirka Merkkaaja',
            'heading' => 'Tempus et hendrerit u',
            'body_text' => 'Sapien eget metus laoreet velit lacus leo ac congue suscipit magna morbi tempor in duis ut nam euismod imperdiet magna finibus ultricies congue.',
        ],
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.

-:)lauri

Tässä tein karvalakkiversion. En ole ihan varma miten tuo sql-aika testataan. Ovatko nuo lukemat edes sinne päin?

sql-haun keston  mittasin näin:

        $start_sql_time = microtime(true);
       
        $sql = "SELECT * FROM {$this->table_name}";
        $res = $conn->query($sql, PDO::FETCH_ASSOC);
       
        $end_sql_time = microtime(true);


toi "Sivun latauksen alusta siihen kun sisältö latautunut" riippuu paljolti siitä, paljonko aikaa kuluu, että serveriltä saapuu kaikki data selaimeen.
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.

-:)lauri

#191
Tässä koodi tuon puun rakentamiselle javascriptillä selaimessa tietokantadatan perusteella. Käytännössä copypeistasin sen täältä: https://typeofnan.dev/an-easy-way-to-build-a-tree-with-object-references/

function treeSort(data) {
    const output = [];
    //console.log(data);
    for(let arr of data) {
        const idMapping = arr.reduce((acc, el, i) => {
            acc[el.id] = i;
            return acc;
        }, {});
        let root;
        arr.forEach(el => {
            // Handle the root element
            if (el.parent_id === null) {
                root = el;
                return;
            }
            // Use our mapping to locate the parent element in our data array
            const parentEl = arr[idMapping[el.parent_id]];
            // Add our current el to its parent's `children` array
            parentEl.children = [...(parentEl.children || []), el];
        });
        //console.log(root);
        output.push(root);
    }
    return output;
}


Toi siis laittaa viesti-tietueen children-muuttujaan viestit, joissa parent_id on kyseisen viesti-tietueen id. Toisessa kohtaa sitten rekursiivisella funktiolla (displayTree) rakennetaan html koodi (alla) ja lopuksi täräyttää tuon koodin näytölle.

function displayTree(tree) {
    let html = '';
    for(let i = 0; i < tree.length; i++) {
        let data = tree[i];
        let children = '';
        if(data.children && data.children.length > 0) {
            children = '<ul>' + displayTree(data.children) + '</ul>';
        }
        html += '<li><div><b>' + data.id + '</b> ' + data.headline_text + '</div>' + children + '</li>';
    }
    return html;
}


Edit: html-koodin rakentaminen hiukka fiksummin sekä siinä olleen bugin korjaus (aiemmin ollut turha str-muuttuja ylikirjoitti itsensä niin, että alkavat li-tagit eivät tallentuneet html-muuttujaan)

Edit, edit: jostain syystä tuo kommentoitu rivi tuotti jokaisen viestiketjun alkuun yhden tyhjän bulletin. Eli en saanut tästä vielä semanttisesti tyydyttävää html-koodia kun lista on tehty pelkillä ul-tageilla.

Edit, edit, edit: nyt sain toimimaan tuon äskön vielä kommentoidun rivin. Virhe tapahtui tuota funktiota aiemmin.
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.

-:)lauri

#192
Tähän viikonloppurojektiin voi tustustua osoitteessa: https://github.com/lazydistribution/tree_structure_testing. Sieltä voi myös downloadaa sen omalle koneelle.

Edit. toteutin tuon ajastuksen paremmin. Nyt ajatus toimii staattisella TimerFeature-toiminnolla. Aiemmin aikaleima sql-ajosta ja tietokantarivien määrä tallennettiin responssiin jo modelissa, nyt ne tallennetaan TimerFeature luokkaan. Nyt siis vasta Response-luokassa (luokka, jossa lopullinen json-tulostetaan) liitetään nuo seurattavat arvot responsiin selaimelle.
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.

a4

Ilman koodaustaitojakin voi näköjään rakennella sovelluksia: https://www.appgyver.com/

Tein parissa minuutissa tämän: https://platform.preview.appgyver.com/322116/kantisapp/page.Page1

-:)lauri

#194
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - lokakuu 06, 2021, 14:29:20
backendistä tuleva json-data

[
    {
        "template": "template-list-item",
        "date": "06.10.2021",
        "text": "Testiteksti 1"
    },
    {
        "template": "template-list-item",
        "date": "07.10.2021",
        "text": "Testiteksti 2"
    }
]


json-datan konvertointi html-dataksi (html-tekstiksi), ja sen tyrkkääminen sivulle

function backendResponse(data) {
    $('#app').html(json2HTML(data));
}

function json2HTML(data) {
    let html = '';
    for(let i = 0; i < data.length; i++) {
        let template = String($('#' + data[i].template).html());
        for(let j of data[i]) {
            if(Array.isArray(data[i][j])){
                data[i][j] = json2HTML(data[i][j]);
            }
            template = str_replace('{' + j + '}', data[i][j], template);
        }
        html += template;
    }
    return html;
}

function str_replace(pattern, fill, str) {
    while(str.indexOf(pattern) !== -1) {
        str = str.replace(pattern, fill);
    }
}


Koska html-sivu on käytännössä puurakenne, pitää fundeerata tätä yo-juttua hiukka uusiksi, kun tosiaan selvisi, että datan järjestäminen puurakenteeksi voidaan tehdä frontendin puolella, säästäen näin serveriltä resursseja.

Tuossa tuo ylempi koodiblokki on hiukka pelkistetty sillä usein se näyttää enempi tältä


[
    {
        "template": "template-list-item",
        "date": "06.10.2021",
        "text": "Testiteksti 1",
        "rows": [
            {
                "template": "template-article",
                "header-text": "Item header 1",
                "content-text": "Lorem ipsum..."
            },
            {
                "template": "template-article",
                "header-text": "Item header 2",
                "content-text": "Lorem ipsum..."
            }
        ]
    },
    {
        "template": "template-list-item",
        "date": "07.10.2021",
        "text": "Testiteksti 2",
        "rows": [
            {
                "template": "template-article",
                "header-text": "Item header 1",
                "content-text": "Lorem ipsum..."
            },
            {
                "template": "template-article",
                "header-text": "Item header 2",
                "content-text": "Lorem ipsum..."
            }
        ]
    }
]


Eli data tulee backendistä valmiiksi puu-rakenteessa vaikka tuon voisi ehkä tuoda frontendiin yksiulotteisena listana kuten alla

[
    {
        "id": 1,
        "parent_id": null,
        "template": "template-list-item",
        "date": "06.10.2021",
        "text": "Testiteksti 1"
           
    },
    {
        "id": 2,
        "parent_id": null,
        "template": "template-list-item",
        "date": "07.10.2021",
        "text": "Testiteksti 2"
    },
    ...
    {
        "id": 120,
        "parent_id": 2,
        "template": "template-article",
        "header-text": "Item header 1",
        "content-text": "Lorem ipsum..."
    },
    ...
    {
        "id": 245,
        "parent_id": 1,
        "template": "template-article",
        "header-text": "Item header 1",
        "content-text": "Lorem ipsum..."
    },
    ...
    {
        "id": 246,
        "parent_id": 1,
        "template": "template-article",
        "header-text": "Item header 2",
        "content-text": "Lorem ipsum..."
    },
    ...
    {
        "id": 428,
        "parent_id": 2,
        "template": "template-article",
        "header-text": "Item header 2",
        "content-text": "Lorem ipsum..."
    }
]


Ja sitten järjestellä se puuksi alla olevan funktion kaltaisella algoritmilla frontendissä

Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - marraskuu 29, 2021, 17:18:07
Tässä koodi tuon puun rakentamiselle javascriptillä selaimessa tietokantadatan perusteella. Käytännössä copypeistasin sen täältä: https://typeofnan.dev/an-easy-way-to-build-a-tree-with-object-references/

function treeSort(data) {
    const output = [];
    //console.log(data);
    for(let arr of data) {
        const idMapping = arr.reduce((acc, el, i) => {
            acc[el.id] = i;
            return acc;
        }, {});
        let root;
        arr.forEach(el => {
            // Handle the root element
            if (el.parent_id === null) {
                root = el;
                return;
            }
            // Use our mapping to locate the parent element in our data array
            const parentEl = arr[idMapping[el.parent_id]];
            // Add our current el to its parent's `children` array
            parentEl.children = [...(parentEl.children || []), el];
        });
        //console.log(root);
        output.push(root);
    }
    return output;
}


Tai en tiedä. Koska tietokannat ovat kaikki erilaisia, datan laittaminen moniulotteiseen listaan eli puuhun jo backendin puolella on osoittautunut hiukka purkkaratkaisuksi kun koodia ainakaan nykyisellään ei voi jälleen käyttää. Vaan jokaisen eri tietokannan ja frontend -implementaatioiden kohdalla tämä on ollut aina ihan erilainen prosessi. Oletan kuitenkin, että implementoimalla tuo id ja parent_id-konsepti, voitaisiin ehkä erottaa parent_id:n käsittely ja sitten tietokannasta otettavan tietueen käsittely ja vakioida työvaiheita.

Kaikki palautuu siihen, onko se kuinka työlästä luoda parent_id-arvo ja liittää se jokaiseen tietokannasta saatuun tietueeseen. Kysymys siis kuuluu, tarvitaanko kuinka paljon sisäkkäisiä looppeja ja jos tarvitaan, onko se sama vaiva, että rakentaa suoraan sen puun, eli että unohtaa suoraan tuon koodin jälleenkäyttömahdollisuuden.

Tässäkin on kyllä vielä se mutta, onko koodi luettavampaa kummalla tavalla. Vanha tapa vai tämä uusi tapa?

Kiehtoo siis ainakin vielä ajatus että voisi koristella yksiulotteista listaa, sillä sen käsittely vaikuttaa ainakin näin ennakkoon simppelimmältä kuin moniulotteisen listan koristelu. Pitää nyt sitten vain odottaa inspiroitumista, jotta saisi kokeilluksi tätä uutta lähestymistapaa.

Tuossa olisi siis ehkä hyvä saada tuo tietueen käsittely niin simppeliksi, että se olisi aina samantyyppinen taski ja että olisi joku erillinen tietokantakohtainen funktio, joka käsittelisi tietokantatietueiden relaatiot, ja tämä olisi käytännössä ainut kohta, joka muuttuisi eri järjestelmissä ja missä kohtaa tarttisi aina hiukka miettiä. Tämä mahdollistaisi sen, että jos olisikin tietokanta-taulu, johon jo tallennetaan tuo parent_id-arvo, ei tarvitsisi miettiä lainkaan :P mutta tietueiden käsittely olisi silti samanlaista kuin muulloinkin - yksiulotteisen listan iterointi läpi, missä kunkin tietueen avain-arvo -parit ajettaisiin esimerkiksi switch-rakenteen läpi lopputuloksena frontendiin lähetettävä yksiulotteinen lista (haluaisin kuvailla tätä switch-vaihetta datan koristeluksi sillä tai vaikka tässä vaiheessa määritellään vain avaimet ja arvot, niiden perusteella frontend kuitenkin tietää piirtää tavaran näytölle). Tietysti switch-rakenne elää hiukka sen mukaan, millainen on design frontendissä, mutta se silti määriteltäisiin tässä aina samassa switch-kohdassa. Näin olisi mahdollisimman paljon vakioituja työvaiheita.
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.