Ohjelmointi

[kertsi]

En ole juurikaan seurannut tätä keskustelua, enkä tiedä onko jo mainostettu, mutta täällä olisi pilvin pimein ilmaisia ohjelmointi- yms. kursseja, esim. https://fitech.io/fi/opinnot/machine-learning-with-python/

Tässä kaikki FITECH-kurssit (joita voi listasta suodattaa).

[-:)lauri]

^
Kiitos, tuohan vaikuttaa hyvältä.

[-:)lauri]

Pitäisi suunnitella MySQL-tietokanta puumaiselle listalle, jossa kullakin nodella on mahdollisesti toisistaan poikkeava määrä tavaraa.

Koodi [Valitse] Laajenna


[
    [
        'id' => 1,
        'parent_id' => 0,
        'created' => '2022-01-04 00:00:00',
        'modified' => null,
        'name' => 'Ensimmäinen kategoria'
    ],
    [
        'id' => 2,
        'parent_id' => 1,
        'created' => '2022-01-04 00:00:00',
        'modified' => null,
        'name' => 'Ensimmäinen myyjä',
        'url' => 'www.ensimmäinen-myyjä.com'
    ],
    [
        'id' => 3,
        'parent_id' => 2,
        'created' => '2022-01-04 00:00:00',
        'modified' => null,
        'name' => 'Ensimmäinen tuote HELGA',
        'url' => 'www.ensimmäinen-myyjä.com/eka-tuote',
        'description' => 'HELGA -kevät mallisto',
        'price' => 5.00
    ],
]


Eli jokainen node on samanlainen neljän (viiden) ensimmäisen avaimen kohdalla: id, parent_id, created, miodified (ja name). Mutta sitten tulevat nuo eroavaisuudet. Tarkoitus olisi kuitenkin saada data ulos tietokannasta juuri ylläolevassa muodossa. Onko ajatuksia?

Olen ajatellut, että eka taulu sisältäisi arvot 'id', 'parent_id, 'created' ja 'modified' ja esim. 'node_content_link_id', jossa taulun id, mistä puolestaan löytyisi kyseisen noden sisällön taulun nimi ja sisällön id. Eli kategoria-noden taulu olisi tyyliin 'category' ja siellä arvot id ja 'name', myyjä-noden taulu olisi 'seller', jossa arvot 'name' ja 'url' ja tuote-noden taulu, jossa arvot 'name', 'url', 'description' ja 'price'.

node-taulu

Koodi [Valitse] Laajenna


[
    'id' => 256,
    'parent_id' => 244,
    'created' => '2022-01-04 00:00:00',
    'modified' => null,
    'node_content_link_id' => 1
]


node_content_link-taulu

Koodi [Valitse] Laajenna


[
    'id' => 1,
    'content_table_name' => 'category',
    'content_table_id' => 1
]


category-taulu

Koodi [Valitse] Laajenna


[
    'id' => 1,
    'name' => 'Ensimmäinen kategoria'
]


Sitten vuan pitäisi keksiä MySQL-haku, joka palauttaa ylläolevan listan edellä mainitusta tallennusHELVETISTÄ, saatana!

[-:)lauri]

Eli nyt kun hiukan pohdin, tämä alla oleva MySQL-query taitaa olla tuo tarvitsemani sql-haku:

Koodi [Valitse] Laajenna


SELECT
  *
FROM
  node as no
  INNER JOIN node_content_link as li ON no.node_content_link_id = li.id
  INNER JOIN li.content_table_name as co ON li.content_table_id = co.id


[-:)lauri]

Tuo palauttaa kaikki tietueet, eli siellä olisi tuolla sql-haulla nyt mukana node-taulun id, liitostaulun id ja sitten se sisältötaulun id, joista kaksi jälkimmäistä eivät sisältyneet alkuperäiseen suunnitelmaani. Mietinkin, että eihän tuo voi noin toimia, mutta sikäli kun niitä id-arvoja tarvitaan tallentamiseen, niin kyllä taitaa olla parempi ottaa nekin ulos tietokannasta jo tässä vaiheessa, jotta saa sitten helposti tallennettua tiedot takaisin tietokantaan. Muussa tapauksessa pitäisi tallentaessa tehdä tuo yllä ollut haku vielä uudestaan id-arvojen selvittämiseksi.

EDIT: eli yhden kategoria-tietueen osalta palautusarvo tietokannasta näyttäisi seuraavalta:

Koodi [Valitse] Laajenna


[
    'id' => 256,
    'parent_id' => 244,
    'created' => '2022-01-04 00:00:00',
    'modified' => null,
    'node_content_link_id' => 1,
    'id' => 1,
    'content_table_name' => 'category',
    'content_table_id' => 1,
    'id' => 1,
    'name' => 'Ensimmäinen kategoria'
]


ja jos käyttöliittymän kannalta turhan datan sitten vielä "pakkaisi" yhteen muuttujaan, voisi palautus arvo näyttää selaimessa joltain seuraavan kaltaiselta

Koodi [Valitse] Laajenna


[
    'id' => 256,
    'parent_id' => 244,
    'created' => '2022-01-04 00:00:00',
    'modified' => null,
    'name' => 'Ensimmäinen kategoria',
    'base64' => 'bm9kZV9jb250ZW50X2xpbmtfaWQ9MSZpZD0xJmNvbnRlbnRfdGFibGVfbmFtZT1jYXRlZ29yeSZjb250ZW50X3RhYmxlX2lkPTE='
]


EDIT: eri taulujen id-avaimet pitäisi tosin nimetä kukin eri tavalla, jotta ne tulisi PHP:n puolelle kivutta. PHP-listassa kun ei voi olla samoja avaimia.

[-:)lauri]

Onko joku keksityn hyvän tavan laittaa selaimen javascript-moottori odottamaan, että DOM on valmis, ennen kuin javascript jatkaa koodin suorittamista, kun tyrkkää string-muodossa olevan html-merkkauksen www-sivulle?

Javascript suorittaa normaalisti kirjoitetun koodin odottamatta, vaikka DOMin päivittäminen on jollain funktiolla kesken, ellei javascriptiä erikseen käske odottaa jotain tapauhtumaa. Jos joku funktio on riippuvainen siitä, että kaikki data on DOMissa valmis, pitäisi jotenkin onnistua kertoa javascriptille, että se odottaisi DOMin valmistumista.

En vain tiedä, onko javascriptissä tällaista DOM-kuuntelijaa. Silloin kun sivu latautuu ekan kerran, siellä on javascriptissä funktio, jonka javascript suorittaa kun DOM on rakennettu valmiiksi, mutta jos päivitän DOMia tämän jälkeen ilman että lataan koko sivua uudelleen, en tiedä, minkä funktion javascript suorittaa silloin, kun DOM on jälleen valmis.

Osaan kyllä laittaa järjestelmän odottamaan tietyn tägin ilmaantumista selaimeen, että jos lisäisin jokaiseen String muotoiseen HTML-merkkaukseen loppuun tällaisen tägin ja jonka poistaisin, kunhan se olisi sinne ilmaantunut. Tämä ylimääräisten tägien lisäily ja poistelu vain vaikuttaa purkkaratkaisulta. Toivoisin tähän kohtaan jonkun geneerisen ratkaisun. Yritin etsiä interwebistä ohjeita, mutta en mielestäni löytänyt juuri muita ratkaisuja kuin laittaa järjestelmä odottamaan jonkun tietyn tägin ilmaantumista sivulle.

Muutenkin voi olla, että olen ajatellut tämän jo alun perinkin hiukka huonosti. Jos tuo String-muotoinen html-merkkaus on massiivinen, saattaa hitaampi selain jäädä jumiin, eli mun pitäisi harjoitella sellaistakin vaihtoehtoa, että tulostaisin datan näytölle pienissä osissa joiden välillä vapauttaisin resurssit koodin suorittamisesta näytölle. DOMin päivitys kestäisi silloin kyllä kauemmin tulla valmiiksi, kuin nyt kun tyrkkään kaiken sisällön kerralla, mutta tuollainen osissa selaimen renderöinti ei tappaisi hitaampaa selainta.

Löytyi toki myös alla oleva esimerkki. En vain tiedä, miten tuon pitäisi toimia ts. miten sitä käytetään. Kun laitoin tuon koodirimpsun kohtaan juuri ennen kuin DOMia päivitin, vaikutti siltä, että done()-funktiota kutsuttiin ennen kuin domia päivitin (else-koodiblokkia ei edes kutsuttu).

Koodi [Valitse] Laajenna


if( document.readyState !== 'loading' ) {
console.log( 'document is already ready, just execute code here' );
done();
} else {
document.addEventListener('DOMContentLoaded', function () {
console.log( 'document was not ready, place code here' );
done();
});
}


[-:)lauri]

^
Opiskelin tuossa juuri työnantajani kuukausittaisen opiskelu-ajan raameissa yhden tunnin mittaisen udemy-kurssin ajatuksesta, johon mm. facebookin ja instagramin DOM-manipulaatiot perustuvat, ja vaikuttaisi sen perusteella siltä, että lähestymistapani on ylipäätään liian yksinkertainen tehtävään, jota yritän ratkoa. Eli jos näytölle tulee paljon tavaraa, niin sen sijaan, että odottaa, että kaikki latautuu DOMiin ennen kuin lisää latautuneisiin tageihin toiminnallisuuksia, pitäisi toiminallisuus lisätä tageihin aina samaan aikaan kuin lisätään HTML-merkkaustekstiin kukin tagi. Näin lienee varminta, että toiminnallisuus myös aktivoituu samalla hetkellä kun kukin tagi viimein ilmaantuu DOMiin.

EDIT, pitää tosiaan tuon perusteella miettiä tarkkaan kannattaako jatkaa nykyistä tapani kirjoittaa koodi jos kohta muutoksin. Eli jatkaisin toiminnallisuuden krjoittamista erikseen ja html-rakentelun erikseen, mutta tällä kertaa niin, että tuo funktio, joka rakentaa html-koodin, osaisi aiemmasta poiketen liittää tuo aiemmin koodissani esittelemäni toiminnallisuus sinne sekaan.

Toisaalta virtuaalisen DOM -kirjaston rakentamin (kuten React -jota tosiaan facebook ja instagram käytävät) saattaisi olla parempi lähestymistapa. Ehkä se tietäisi muutaman rivin enemmän koodia, mutta se korjaisi samaan aikaan muutaman muunkin ongelmakohdan, kuten sellaisen, että kaikkea dataa ei tarvitsisi päivittää DOMissa joka kerta uudestaan, kun joku yksittäinen atribuutti tai arvo muuttuu jossain tagissa, vaan kuten virtual dom mahdollistaisi, vain tuo tagi.

[-:)lauri]

^
Nyt näyttäisi siltä, että sain myös tuon virtual DOMin koodin toimimaan tässä mun koneella. Tämä avannee uusia mahdollisuuksia. Pitää vaan keksiä käyttökohteita. Varmasti pienemmissä sovelluksissa toimiva ratkaisu, jos kohta tuo mun alkuperäinen toimii vielä pienemmissä sovelluksissa. Kuitenkin vaan sitten rohkeasti Reactia, mikäli tarvitsee isompaa systeemiä.

[-:)lauri]

Mä olen nyt viimeisimmäksi yrittänyt duunaa geneeristä ascii-taulukkogeneraattoria php:lla*, mutta jostain syystä wordwrap-ominaisuus on tuottanut sellaisia ongelmia, ettei rojekti oikein etene. Tein yhden "version" jo valmiiksi, kun tein nämä listat, mutta tuossa koodi oli riippuvainen sekä ladatun tiedoston tietorakenteesta, että otsikkorivin wordwrap-toiminto puuttui, ja jouduin itse rivittämään otsikon.

Mulla on nyt tässä uusimmassa versiossa ainakin aihio wordwrapille.

Löytyy tuo aihio testiketjusta: https://kantapaikka.net/index.php/topic,3.msg131290.html#msg131290

Se toimii muuten oikein, mutta se käyttää edelleen vain yhtä rivin maksimipituuden arvoa, vaikka sen pitäisi käyttää jokaiselle taulukon sarakkeelle kyseisen sarakkeen maksimileveyttä. Eipä tullut aiemmin mieleen kun ei ollut tarvetta rivittää muita sarakkeita kuin vain taulukon viimeisintä saraketta. Samoin tuossa on edelleen se ongelma, että tämä aihionikin on edelleen liikaa riippuvainen tietorakenteesta. Tarkoitan, että mulla on nyt listoja listojen sisällä, joissa osa avaimista tekstinä ja osa numeroina. Tekstiavaimia varten pitää kirjoittaa omat funktiot kun taas numeroavaimia varten voi käyttää PHP:n omia funktioita.

Pitäisi päästä tilanteeseen, jossa taulukko-kirjasto käsittelisi vain kaksiulotteisia listoja. Eli listoja, jotka sisältäisivät tiedot vain taulukon jokaisen rivin tiedoista. Ulompien listojen pyörittelystä vastaisi sitten muut ohjelman osat. Tämä auttaisi siinä, että valmistamaani taulukkokirjastoa voisi käyttää myös jatkossa kokonaan erilaisen datan kanssa. Vielä ei kuitenkaan ole kaikki menetetty wordwrap-toimintoni osalta, sillä seuraavaksi pitää vain poistaa ulommat listat ja jättää jäljelle tosiaan vain operaatiot koskien kaksiulotteista listaa. Sekä katsoa missä kohtaa iteroin rivitystä tehdessäni läpi sarakkeita, jotta voin esitellä PHP:n omalle wordwrap()-funktiolle oman sarakekohtaisen leveyden.

Mutta jokaisella pilvellä on hopeareunuksensa. Tässä projektissa olen jostain kumman syystä opetellut käyttämään array_reduce()-funktiota. Nyt osaan käyttää sitä. Tosin vanhaa taulukon iterointia sekään ei voita, mutta joissain tapauksissa array_reduce-iterointi vaikuttaa mielestäni luonnollisemmalta vaihtoehdolta kuin perinteinen taulukon iterointi foreach-loopissa. Saas nähdä tulenko milloin käyttämään juuri oppimaani jossain työprojektissani.

* En ole katsonut mallia mistään, mutta sittenkin olisi pitänyt, sillä näitä on käsittääkseni tehty läpi koko tietokoneiden käyttöhistorian ajan sillä mahdollisesti edelleen se yleisin koodarien käyttämä käyttöliittymä on joku tekstikäyttöliittymä. Mutta jotta käyttäisin valmista sovellusta, pitäisi löytää PHP-kielellä toimiva sellainen kirjasto, jossa olisi tuon wordwrap-toiminto, sillä kovin pitkiä tekstejä ei ole mielekästä pakottaa yhdelle riville. Listojakin kun voisi olla ihan kiva välillä voida katsoa kännykän ruudulta ilman että joutuu kääntelemään luuria. Ties vaikka saisi tyrän liian aktiivisesta "luurinkääntelystä". Olisi tosin senkin vuoksi hyvä ollut katsoa mallia jostain kun tässä on kokoajan käynyt eri parempia ja parempia versioita tehdessä selväksi, että millainen politiikka olisi järkevää siinä miten organisoida ja jaotella koodi omiin kategorioihinsa ja selvittää niiden työtehtävät. Jossain valmiissa sovelluksessa nämä on ja ajateltu valmiiksi eikä tarvitsisi aloittaa kokoajan alusta kun huoman, että olisi parempi organisoida koodi toisella tapaa.

[-:)lauri]

^

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.

Toinen syy, miksi rojekti ei oikein etene, on se, että en edelleenkään tiedä, miten Ajax-endpontin koodi olisi järkevintä organisoida, ja se taas liittyy tuohon tähän viestiini ylle lainaamaani asiaan kosien aiempaa projektiani, jossa idea oli tehdä mahdollisimman kevyt "API".

Jos tuossa viime marraskuisessa rampagessa idea oli alun perin testailla vain puurakenteen renderöintiä, niin tein sen yhteydesssä ja siihen tarpeeseen sivuprojektina kevyen apin. Tälläkin kertaa mulla on ollut pääasiallisena motivaationani listata saksitut-ketjuun päätyneiden viestien lukumäärät per nimimerkki ascii-listaan ja sitten taas tälläkin kertaa on ollut vahvasti mukana yritelmä vastata kysymykseen mahdollisimman lightway-tietorakenteesta ajax-kutsuja varten, mikä tarjoaisi kuitenkin riittävästi järkeviä käytäntöjä, joita noudattamalla koodia on helppo seurata.

Viime marraskuun projekti oli edelleen ja selvästi liian raskas, koska en kokenut luontevaksi ottaa sitä nyt käyttöön. Se kelpaa hyvin argumentiksi sen käytännöllisyyttä vastaan.

Kehitinkin nyt siis vieläkin kevyemmän version, jos kohta endpointtien määrittely ei nyt edellisestä poiketen tässä versiossa tyydytä (en kamalasti pohtinut tätäkään toteutusta kunhan vain roiskin MVC-ratkaisuni mahdollisimman nopeasti pöytään). Nyt kuitenkin haluaisin ehkä sittenkin kirjoittaa endpointit samoin kuin ne voidaan kirjoittaa esimerkiksi Laravelin MVC-kirjastossa. Eli tyyliin funktiokutsu, joka ottaa parametreinä vastaan url-osoitteen loppuosan, jota ajaxilla kutsuttu ja sitten käsittelijä rakenteeltaan: ClassNameController@methodName, jossa ekana controller-luokan nimi sitten @-merkki ja sen jälkeen controller-luokassa olevan metodin nimi, joka kyseisen ajax-kutsun backendissä käsittelee.

Esimerkki endpointista jollaista haluaisin käyttää olisi seuraava:

Route::get('/users', 'UserController@index');
Route::post('/upload', 'FileController@upload');

nyt mulla kuitenkin on tällainen lista-toteutus

return [
    '/users' => 'UsersController@index',
    '/upload' => 'FileController@upload',
];

Mulla on käytössä App-niminen luokka, joka käsittelee nuo listana esitellyt endpointit, kun ajattelin esitellä suoraan App-luokan, jos jatkossa tarvitsee jotain järeämpää, mutta ehkäpä pitäisi duunaa nyt vain suosiolla tuo Route-luokka ja lisätä sitten joskus myöhemmin App-niminen luokka jos järeämpää tarvitsee. Mieluummin liian yksinkertainen ja pysytellä yleisimmissä nimeämiskonventioissa, jotta ei sido käsiä siinä mitä käyttöä tällä on jatkossa. On vain niin hankala tietää etukäteen käyttötarpeita.

Tää on tällainen ikuisuuskysymys sekä selvästi ikuisuusprojekti. Samaten voisi olla vieläkin fiksumpaa nähdä se vaiva ja ladata joka kerta käyttöön Laravel näihin pikku projekteihinkin. Oppisi käyttämään sitäkin pelkän näpertelytason osaamisen sijaan.

[-:)lauri]

Joku seuraavista projekteista voisi olla tuo mun localhost-kansion www-navigoinnin uudelleen väsääminen. Alla kuva nykyisestä. Siinä silmä lepää. Eli visuaalisesti perusrakenne on jo mieleiseni.

Musta painike on kansio, muun värinen painike yleensä jotain muuta sisältöä, kuten esimerkiksi suoritettava tiedosto.

Ongelma on, että jos availen kansioita tuosta pitemmälle kansiorakenteen syövereihin ja avaan sieltä jostain jonkun sivun selaimeen ja sen jälkeen painan selaimesta back-nappia, tuo palaa kansiorakenteen juureen eikä siihen näkymään, jossa oli tuo äsköinen kansiorakenne auki. Tämä on ongelma. On hiukka epäkäytännöllistä joutua klikkailemaan taas kaikki kansiot auki siihen viimeisimpään näkymään jos paikka oli edellisellä kerralla oikea, mutta tiedosto oli väärä.

En käytä nyt juurikaan osoiteriviä kuin sen käyttämisen mahdollistamaa selaimen historiaakaan. Pitäisi käyttää jotta selaimen back nappi löytäisi oikean sisällön. Toinen vaihtoehto varmaan olisi tallentaa viimeisin kansiorakenne keksiin. Luullakseni lähestymistapani tulee kuitenkin olemaan osoiterivi. Silloin sivu toimisi semanttisesti oikein.

Toinen idea olisi uusi feature. Se olisi sellainen, että esimerkiksi tekstitiedoston tai muun suoritettavan tiedoston kohdalla kun painaisi riville ympättyä toista nappia avautuisi teksti/koodi tuohon sivulle grafiikan päälle. Näin voisi tarkistaa ennen sivun avaamista ettei suoritettava koodi saa aikaan ei-toivottuja sivuefektejä koneella.

Kolmaskin idea on. Eli riville voisi lisätä kolmannen, neljännen tai ehkä viidennenkin painikkeen, jota/joita painamalla, kansion tai tiedosto avautuisi joko vs codeen, notepad plus plussaan tai kansion ollessa kyseessä, ehkäpä windows power shelliin.

Tämä kolmas idea parantaisi käyttökokemusta kun ei tarvitsisi avata välttämättä erikseen exploreria, että saa koodin auki ohjelmaan.

Neljäs idea liittyy tuohon kolmanteen. Voisi lisätä painikkeen, josta lisätään kansioon uusi kansio tai tiedostotyyppi.

Viides idea tarkoittaisi neljännen idean jatkamista niin että luodun kansion saisi haluamallaan sisällöllä. Mulla on tuolla muutama template-kansio järjestelmässä jotka olisi kiva kopioida uuteen paikkaan ja sitten avata esimerkiksi vc code uuteen kansioon. Näin ei tarvitsisi windowsin omaa exploreria.

[-:)lauri]

^
Koska tämä olisi spa-sivu (single page application), selaimen back-napin toimiminen edellyttää tässäkin tapauksessa, että selain pystyy lukemaan sisällön kannalta järkevää tietoa osoiteriviltä, osatakseen ohjeistaa backend valmistamaan oikeanlaista dataa.

Pitäisi siksi keksiä järkevä protokolla tuohon osoiteriviin.

Jos vaikka vain laittaisi kansioiden nimet peräkkäin erikoismerkillä toisistaan erotettuina: ehkäpä hieman kuten tässä tapauksessa. Sitten laittaa nuo rivit peräkkäin ja erottaa ne toisistaan jollain muulla erikoismerkillä. Lopulta enkoodaa syntyneen yhden rivin tekstin, jotta sen voi laittaa osoiteriville. Jos näkymässä on suljettuna oleva kansio tai filu, niitä ei luonnollisesti tarvitsisi sisällyttää tuohon osoiteriville. Seuraavaksi selain ottaisi tuon osoitteen ja lähettäisi sen backendille. Backendin tulisi osata selvittää kyseisestä tekstirimpsusta kansiorakenne ja palauttaa sen perusteella oikeasisältöinen json-data-paketti selaimelle.

Edellinen-notaatio näyttäisi piippu- ja tuplapiippu-tapauksessa aseuraavan laiselta ilman enkoodausta (selain ei ymmärrä tätä osoitteeksi)
https://mozilla.org/level one|two|three||level one|another||level one|aaa|bbb|ccc||level one|aaa|bbb|aaa

Ja sitten enkoodauksen kanssa (selain ymmärtää tämän osoitteeksi)
https://mozilla.org/level%20one%7Ctwo%7Cthree%7C%7Clevel%20one%7Canother%7C%7Clevel%20one%7Caaa%7Cbbb%7Cccc%7C%7Clevel%20one%7Caaa%7Cbbb%7Caaa

Tämä on alustava sotasuunnitelma, kuinka rakennan url-osoitteen kansiorakenteelle. Onko muilla ideoita, kuinka kansiorakenne olisi näppärä laittaa selaimen osoiteriville?

[-:)lauri]

^
Tässä onkin saanut jumpata, että sain backendin ymmärtämään tuota tekstinotaatiota. Olisi pitänyt heti alkuun muuttaa kukin rivi id ja parent_id -muotoon niin olisin saattanut jo heti alussa hyödyntää tota mulla jo viime marraskuulta valmiiksi ollutta javascript-implementaatiota puurakenteen luomiseksi. Pienillä muutoksilla se istui näppärästi php-koodiin.

Sen jälkeen eksyin useiksi tunneiksi rekursiivisten funktioiden mielettömyyteen.

Vihdoinkin backend palauttaa oikean informaation tuolla notaatiolla... ...tai niinhän mä luulen. Sekin ottaa oman aikansa, että saa frontendin toimimaan niin, että se lähettää backendille tarpeellisen notaation. Backend palauttaa kunkin painikkeen notaation, mutta en ole ihan varma riittäkö, että tyrkkää notaation kylmästi vain osoitteen jatkeeksi.

Vielä kun ajattelin tehdä frontendin reactilla niin tämä saattaa kestää. Backend on tehty ainakin tältä tiedostolistauksen osalta Laravelilla.

[-:)lauri]

p5.js kirjasto ei ole tehty modulaariseen ohjelmointiin. Tai sitten react-p5 -kirjastossa on bugeja. Tai sitten en vaan osaa käyttää sitä. Tai sitten kaikki edelliset yhteensä.

Yritin rakentaa react-p5 -kirjastolla grafiikkaa reactissa, mutta tyhjän olisi saanut pyytämättäkin. Kaikki grafiikka ei siinä päivity näytölle riippuen siitä, missä komponentissa ne olisi tarkoitus piirtää näytölle. Yhdessä komponentissa grafiikka piirtyy näytölle kun taas toisessa komponentissa ei. Jos tuon komponentin, jossa grafiikka ei päivity näytölle, näytölle renderöinnin toteuttaa pääohjelmassa niin tuo äsköinen vielä toimivasti palikat renderöinyt komponentti lakkaa päivittämästä osan komponenteista näytölle. Eikä interweb tunne juurikaan keskustelua kuinka p5.js kirjastoa käytetään modulaarisessa ympäristössä.

Pitää joko yrittää luoda grafiikka vanilla-javascriptilla reactissa tai sitten pitää tehdä grafiikka erikseen ja ladata se sivulle. Melkein kiinnostaisi tää jälkimmäinen. Eli jos vain lataisi grafiikan iframeen ja löisi sen taustalle pörräämään. Mulla nimittäin on versio haluamastani grafiikasta jo tehty, joten tarvetta sen uudelleen kirjoittamiselle reactissa ei varsinaisesti ole. Tekisi tosin siksi mieli kirjoittaa se uusiksi reactissa, että olisi sitten tuosta grafiikastani modulaarinen versio olemassa, jonka myötä opittuja käytäntöjä voisi hyödyntää muissa modulaarisissa projekteissa.

[-:)lauri]

^^
Pitänee mennä Stack Overflow:hun kyselemään typeriä. En nimittäin tiedä, kuinka tarvitsemani navigointi toteutetaan Reactissa tai että millaista navigointia ylipäätään Reactissa tarvitsen.

Olen kerran aiemmin tehnyt vanilla javascriptilla systeemin, jossa laitan osoiteriviin kuuntelijan, joka aktivoituu joka kerta, kun osoiteriviä muutetaan. Aktivoituessaan kuuntelija tilaa backendistä tiedot osoiterivillä olevien tietojen perusteella, jotka näytetään sitten sivulla. Eli kuten homma toimii staattistenkin nettisivujen kanssa. Tämän tyyppistä toiminnallisuutta suunnittelin myös nyt tuohon "explorer"-projektiini.

Reactiin on saatavissa React Router -lisäpalikka, joka operoi selaimen osoiterivin kanssa, mutta tietääkseni sitä käytettäessä pitää esimerkiksi osoitteiden olla staattisesti määriteltyjä kun taas minulla ne määräytyvät dynaamisesti. Mutta koska en tunne Reactia riittävän hyvin, pitää mennä kyselemään.

Samaten pitää siirtyä queryparametrien käyttöön. Päinvastoin kuin ekaksi ajatelin, että osoite olisi muotoa localhost/toc/public/www||www|assets, jossa www-kansion sisältö tulisi suoraan kauttaviivan perään, pitää muuttaa tuo esimerkiksi muotoon localhost/toc/public/?q=www||www|assets, tämä mahdollistaa sen, että voin välittää backendille näppärästi muutakin tietoa halutusta näkymästä kuin pelkän kansiorakenteen.