Single page html

Internet: PHP, CGI, stb.

Össze kellene dobnom egy html+css+js weboldalat (mindenféle belső logikával + jquery esetleg), ahol feltétel, hogy egy file legyen az egész. Nem egy bonyolult dolog, mivel a html-be a js és a css is beleerőltethető, de a gondom az, hogy egy brutálisan átláthatatlan szörny jön létre, amit én jobb szeretnék külön (egymásba includolt) fileokban írni, debuggolni, majd ha működik, a végén összeeszkábálni belőle az egy nagy html-t.

Létezik erre a problémára valami nem ágyúval verébre (tehát ne kelljen egy drabális frameworkot használnom hozzá) megoldás?

( Crayon | 2019. 07. 12., p – 14:01 )

nem tudom nálad honnatól számít ágyúnak, de babel vagy webpack.
Ha framework is szóba jöhet akkor pedig VueJS

egy specialis geprol kell valamit letolteni es elinditani, ahol jelenleg csak 1 konkret url-t tudok kihasznalni, tehat erre az 1 url-re tudok akasztani 1 statikus html-t. Nem standard webszerver szolgalja ki, tehat parameterezni sem tudom, semmi mast nem tudok vele csinalni. Egy olyan szolgaltatast hasznalok, ami nem erre van kitalalva :)

PHP nagyon egyszerűen használható erre, de tovább megyek, tudsz egy sablonokat js számára elérhetővé tevő script-et is írni pár sorban, teljesség igénye nélkül: php felolvassa a html mappa fájljait, és betölti őket egy js arraybe lang['filenév'] alá. Utána hogy már milyen regexp-eket futtatsz rá a js oldalról elég rugalmasan kezelhető, de az eredmény egy darab js fájl, amiben benne van az összes sablonod. Ugyan így ha pl. cfg fájlt akarsz írni, adatbázis hiányában, az is szög egyszerűen írható egy js fájlba is direkten, de akár azt is lehet más fájlformátumból php-val feldolgozni js-é.

Senkinek nem javaslom jó szívvel a saját sablonkezelő írását, de közel sem akkora lehetetlenség és eszetlenség, mint sokan szeretik hangoztatni.

Figy, egy 5 soros php kódnál azért nem sok minden tud egyszerűbb lenni. Mi az amiben rosszabb? Nyilván ha komolyabb js fejlesztésbe akar kezdeni, akkor érdemes megfontolni, de ha csak azt szeretné, hogy 5 js és 3 css fájlból egy html legyen az eredmény, akkor ágyúval verébre egy komplett infrastruktúra összerakása.

Nekem ez most a kalapács van a kezedben és mindent szögnek nézel esetet idézi.

Miért kókányolnva PHP-val, amikor van erre céleszköz?

Nekem fél éve volt egy hasonló problémám, szerettem volna egy gyors PoC-t összerakni egy singe-page kis wizardra ami segíti a fejlesztők munkáját.
A Google kereséstől és a webpack megtalálásától számítva a kis bootstrapes, jquerys, működő dolog webpackkel, Nginx-es Docker builddel és az egészre egy build pipelinenal, kis dokumentációval együtt 2 óra alatt megvolt.

Vállalható, könnyen folytatható megoldás lett és magasan teljesítette, hogy ne ágyúval verébre esete legyen.

2 órát állítasz szembe egy 10 soros php script-el, ami arra pont elég, hogy ne kelljen egy fájlban matatni, hanem lehessen kultúráltan dolgozni. Nem volt igény összetett sablonkezelésre, 3rd party pluginek tesztjeire, részletes böngésző kompatibilitásra, ... Majd ha van értelme hetekig-hónapokig fejleszteni a project-et, akkor megtérül a dokumentáció olvasgatás egy teljesen új eszközről. És az esetleges workflow debugging, mert az sem jó vicc, amikor "életem első node project-je, és lehalt valami". Nekem ágyúval verébre az is, hogy nginx, docker szóba kerül ott, ahol egy várhatóan egyszerű alkalmazásról van szó, aminek az összeállításában csak a fejlesztői gép vesz részt, az eredménye egy html fájl, ami felkerül egy szerverre. Vagy rosszul gondolom, és ezt docker-be kéne rakni a célgépen is?

Egy kérdés: alkalmazott vagy vagy vállalkozó? :)

Nem azert irtam a tobbi lepest, hogy ugy kell mindenkinek csinalni.
Nekem az volt a cel, hogy legyen egy artifact amit a sokszaz fejleszto azonnal tud hasznaln ha fellovik a sajat kornyezetukben vagy a projekt altal preferalt cloudon.
Aki pedig vinni szeretne tovabb, annak is egy hasznalhato strukturaja legyen.

Egy kérdes: miert relevans?

A fentiekből (nyitó poszt és hozzászólások) nekem úgy tűnt, hogy inkább nyűg, mint jövőbeli fő fejlesztési irány a project. Ezért alapból azt a hozzáállást javasoltam, hogy akkor ne infrastruktúrát építsünk, hanem valami faék eszközt, ami tényleg rugalmas és gyors, nagyon kevés a hibalehetőség (kb. 0), és eséllyel már ismeri a kolléga, vagy ha nem, tényleg 4 perc alatt megtanulható. A megfontolásaid helyesek, ha az a cél, hogy 5 év múlva is használható legyen a project, 25 másik programozó által is, bővítve lesz, stb., de úgy sejtem nem egészen ez az irány. Egyébként ebben az esetben sem feltétlen akkora gond, ha nincs egy komplett keretrendszer a project-be behúzva, a php itt tényleg CSAK azt végezné el, hogy x db fájlból 1 legyen, esetleg alap sablonokat töltene be, és kész. Ezt átlátni, és adott esetben ha kell, kicserélni azért nem agysebészet (ha az idő úgy hozza, hogy a project nő).

A kérdés azért lehet releváns, mert multis környezetben alkalmazotti szempontból kevésbé kerül megfontolásra minden perc, ne értsd félre, nem személyeskedés, de multis környezetben nem centire kiszámolt budget van, hanem emberileg jobban figyelembevett határok, van lehetőség tanulni, fejlődni, vállalkozók (főleg egyéniben) sokkal kevésbé tartják viccesnek, ha egy "csak kell" project-nél 2-3 órát olvasgatnak úgy, hogy nem igazán tudják most azonnal megmondani milyen előnye lesz a technológiának amit használni akarunk, csak hát így szokás, ez a best practice, meg majd megtérül a jövőben. Biztos? Mi az amit a babel a fent ismert adatok alapján megkönnyít, valójában használható ide? Ismert-e hogy kellenek-e egyáltalán polyfill-ek, böngésző kompatibilitás, jquery-nél összetettebb framework, vannak-e 3rd party plugin-ek amik léteznek node-os környezetben, ...

Lentről építkezek, mert minden ami nem térül meg, az nekem került pénzbe. Alkalmazottként, több fős csapatban, nagy project-nél, ezek nem tűnnek fel, nem is könnyen kimutathatóak, főleg ha már van abban a stack-ben ismereted. A kérdezőnek nincs, különben az egész szál nem indult volna el.

Nem webfejlesztőként azért sem érdemes webes technológiák tanulására időt fordítani, mert mire legközelebb ilyesmire adod a fejedet, addigra már mások lesznek a divatos technológiák :-)

Ami projektet ma csinálsz, az pár év múlva le sem fog "fordulni". Ezért is érdemes itt valami faék egyszerűt csinálni. Berakod a forrást egy verziókezelőbe, és akár 5 év múlva is hozzá tudsz nyúlni, mert PHP 5, sőt 25 év múlva is lesz. A ma divatos csili cuccokkal meg ki tudja mi lesz. Az npm alapú csodával dolgozva egy fájlt leszed valaki az internetről 4 év múlva (lásd leftpad), és 5 év múlva amikor elővennéd a cuccot úgy elakad a folyamatod, hogy sose jössz rá, hogy mitől. Persze csinálhatsz a függőségeidre saját mirrort, meg eltehetsz egy mai oprendszert - de egy pár napos projekt miatt az már azért túlzás volna.

( tomsolo | 2019. 07. 12., p – 18:53 )

mivel mind a js, mind a css beágyazható a htmlbe nem igazán értem a problémádat

megírod linkelve, majd a végén beágyazod őket a megfelelő tag-ek közé... (%)

[új] - No rainbow, no sugar - [új]

Igen, ezt irtam, hogy igy meg tudom csinalni. Csak nem vagyok mazochista es tenyleg nincs kedvem 1 darab fajlban menedzselni egy tobb aloldalbol allo html-t, a hozza tartozo logikat, az egyes klikkekhez kapcsolodo js funkciokat, minden aloldal tartalmat, a css-t es az amugy kulsokent hasznalt js-ket (tipikusan jquery es pluginjei).

( kila | 2019. 07. 13., szo – 17:12 )

Nézd meg a TiddlyWiki-t https://tiddlywiki.com/, hogy abban hogy csinálják.
Ami neked kell, azt lehet hogy elég egy pluginként megírni hozzá.
--
Légy derűs, tégy mindent örömmel!

( harlequin | 2019. 07. 14., v – 16:41 )

Mindenkinek köszönöm a segítséget :)