Röviden.
Symfony 7-ben írok egy rendszert. A miérteket hagyjuk, de kénytelen vagyok custom route loadert írni alá a doksik alapján.
Adatbázisból szedem ki az url-eket, több nyelven és onnan töltöm fel dinamikusan.
Nagyon sok doksit átolvastam, átnéztem fórumokat. Nem jöttem rá hogy kéne felvinni több routingot egy name alatt több nyelven.
Tehát ha pl twig-ben azt mondom, hogy {{ path('homepage') }} akkor irányítson át az aktuális nyelv alapján a megfelelő oldalra, pl /hu/fooldal vagy /en/homepage
Attribute-k segítségével ez elvileg megoldható a controllerek alatt, de itt nem jöttem rá hogy lehetne, a doksik alapján se.
Persze megoldható, hogy suffix-al a route name mögé beteszem a locale-t, pl homepage_hu, homepage_en, stb, aztán twig-ben a path mögé mindig befűzöm a locale-t, vagy írok rá egy twig function a path helyett.
Gondoltam nézzük meg az AI-t, mit mond. 2-3 kérdés után eljutottam oda, hogy adott megfelelő példakódokat. Az alapján csak simán adjam hozzá újra és újra a Route-kat, különböző locale paraméterekkel. Persze próbáltam már, de megnéztem úgy is ahogy ő írta. Hát nem működött. Nyilván.
Mondom neki, ez nem megy, felülírják egymást az azonos name-k. Erre visszaírja, hogy jaaa, ha felülírja, akkor tegyem mögé sufffix-ban a locale-t, bla-bla. Azt a végén ugyanazt találta ki ami már nekem is eszembejutott.
Szóval, többen is írtuk már, hogy kb találgat az AI, próbálkozik. Azt nem értem, hogy valóban emberek fejlesztenek vele? Vagy ezt csak a kezdők használják? Hisz végül is ha azt nézzük ugyanúgy eljutottam ugyanarra a pontra simán google-zással is.
Persze nála gyorsabban megvoltak a válaszok, csak épp döntsem el, hogy most mikor "kamuzik". Nála csak egy állítást látok, viszont ha stacko-n találok egy választ amit 100-an értékeltek, akkkor az közel 100%-os biztosság. Ugyanígy a doksiban olvasva szintén többet ér mint egy benyomott AI komment.
A megfelelő kérdésekkel sincs baj, hisz kb 3 kérdés után megvolt a válasz.
Szóval én azt hiszem maradok a doksiknál és a google kereséseknél.
- 2151 megtekintés
Hozzászólások
Az "intelligens mosópor" megvolt? A ChatGTP csak egy nyelvi modell.
- A hozzászóláshoz be kell jelentkezni
Jójó, de álltólag mégis ezzel dolgozik rengeteg fejlesztő :D
- A hozzászóláshoz be kell jelentkezni
Úgy érted hogy annyira jó kódot írnak, hogy kizárt hogy az AI-ból jöjjön?
Nincs nagy ugrás. Eddig a stackoverflow-t másolgatták ész nélkül, most a csetbotok szülte okosságot. Annyival nem hülyébb a csetbot, mint a random jószándékú.
- A hozzászóláshoz be kell jelentkezni
Tehát ha pl twig-ben azt mondom, hogy {{ path('homepage') }} akkor irányítson át az aktuális nyelv alapján a megfelelő oldalra, pl /hu/fooldal vagy /en/homepage
Ezt miért nem inkább egy HTTP rewrite-al oldod meg? Nem terhelné se az adatbázisszervert, se a szkriptfuttatás a webszervert minden egyes oldalbetöltésnél.
Csak egy helyben futtatott szkript kell, ami kiolvassa az adatbázisból az URL-eket és legyárt hozzá egy, a webszereverdnek megfelelő HTTP rewrite konfig fájlt, amit meg beinclude-olsz a webszervered konfigjába. Ezt a szkriptet csak akkor futtatod le, ha új URL születik, egyébként nem (a te route megoldásod minden egyes oldallekérést terhelné).
Apachenál RewriteRule, nginx-nél simán rewrite és lighttpd-nél is rewrite, stb. Nem tudom, hogy a nyelvet konkrétan honnan veszed, de mindegyik tud HTTP header-re, browser-re, query-re vagy cookie-ra is match-elni.
Pl. nginx alatt valami ilyesmi kell (feltéve, hogy a nyelvkód sütiből jön):
if ($http_cookie ~* "lang=en") { rewrite ^/homepage$ /en/homepage rewrite ^/about& /en/about ... } if ($http_cookie ~* "lang=hu") { rewrite ^/homepage$ /hu/fooldal rewrite ^/about& /hu/rolunk ... }
Ha angolnál csak elé akarod rakni, hogy "en", akkor oda elég egyetlen sor is,
rewrite ^(.*)$ /en/$1
Magához a honlap kódjához hozzá sem kell nyúlni, a Symfony 7 routing marad, ami volt, csak a nyelvspecifikus URL-ek kellenek bele, semmi más.
- A hozzászóláshoz be kell jelentkezni
Egyrészt ha frameworköt használok, akkor ragaszkodom hozzá, hogy úgy menjen minden ahogy ott kitalálták, a doksi szerint.
Semmiképp sem lenne előnyös egy meglévő url-t elfedni egy új-al. Amikor php-ból akarsz url-t generálni, akkor se a konkrét url megadádával teszed, hanem csak egy kódnevet adsz át neki. A háttérben ő pedig előbányássza az url-t. Így az url-t bármikor megváltoztathatom, a kódban nem kell a template-k alatt átírni.
Ez így jó is, ez így van kitalálva. Persze így dolgozik a php is, de van cache.
az pedig nem utolsó szempont, hogy egy htaccess-t problémás admin felületre kivezetni. Nálam az a lényeg, hogy adminban át lehet írni az url-ejket, bármelyik nyelven.
- A hozzászóláshoz be kell jelentkezni
Nem értettél meg.
Amikor php-ból akarsz url-t generálni, akkor se a konkrét url megadádával teszed, hanem csak egy kódnevet adsz át neki.
Ugyanúgy php-ból generálod ugyanazzal a framework hívással az URL-eket itt is, csak route helyett webszerver konfig fájlt csinálsz belőlük kimenetnek.
A háttérben ő pedig előbányássza az url-t.
Pontosan ugyan úgy itt is. A különbség csupán annyi, hogy nem minden egyes oldalbetöltést terhelsz az előbányászással, hanem csupán csak akkor futtatod le, amikor változtatsz valamelyik URL-en.
A php által az adatbázisból előbányászott URL kerül a a rewrite konfigfájlba (tekintsd úgy, mintha ez egy routing cache lenne). Ha az adatbázis változik, újra lefuttatod és frissül a "cache".
egy htaccess-t problémás admin felületre kivezetni
Nem kell hozzá semmiféle külön admin, mehet akár egy hook-ból is, automatikusan, a már meglévő admin felületről hívva. Vagy mehet akár függetlenül cron-ból is éppen, az már tökmindegy, a lényeg, hogy nincs szükség külön adminfelületre hozzá, hisz ez a szkript pontosan ugyanazzal az interfésszel bányássza elő az URL-eket, ahogy egyébként is tennéd.
Mégegyszer, minden ugyanaz, annyi csak a különbség, hogy a nyelvfüggetlen URL-eket a rewrite konfigba írod, a nyelvfüggő URL-eket meg hagyod, hadd menjenek a szokásos Symfony 7 route szerint.
(Mivel a rewrite már a HTTP kérésben lecseréli az URL-t, ezért az sem probléma, ha a nyelvfüggetlen URL-ek is bennmaradnak a Symfony 7 routingjában, senkit nem fognak zavarni.)
Nem jöttem rá hogy kéne felvinni több routingot egy name alatt több nyelven.
Fordítva ülsz a lovon. Felveszel egy oldalt, mondjuk "/hu/fooldal" routinggal, egy másikat pedig "/en/homepage" routinggal. Mindkettőnek megadod ugyanazt az aliast ("homepage"). Szóval nem egy oldalhoz veszel fel több routingot, hanem minden routing külön oldal.
- A hozzászóláshoz be kell jelentkezni
Nyugi, ismerem a rewrite-t. 10+ éve is használtam.
Ha nem lenne nyelvi routing, csak semleges egységes, akkor is be kell töltenie egyszer azt is. Nem nyersz vele komolyabb erőforrást. ezzel csak bonyolítanád a rendszert.
Ugyanúgy betöltődnek az url-ek a framework alól, csak nem nyelvi verziók, hanem az amit te rewrite-val töltenél be.
Az admin felület alatt arra gondoltam, hogy ott szerkesztik alapból az url-eket és fordítják le.
Értem, hogy mit akarsz mondani, de fejlesztés oldalról ez a megoldás nem valid. Ha frameworkben dolgozol, akkor nem írunk fölé custom megoldásokat, max akkor ha azt az igényt nem lehet megoldani benne. Viszont ha valami általános igényre nincs benne megoldás, akkor az azt jelenti, hogy az a framework szar.
Nem azért nem fejlesztel fölé egyedi dolgokat mert nem tudom megoldani, hanem mondhatni ez egy irányelv. Így lesz a kód egységesebb. Ha egy másik fejlesztő belenézne a kódomba és meg akarná érteni, akkor az említett részben a routingolást kell kidoskiznia és már értené is. Ha adatbázis lekérdezéseket szeretné megérteni, akkor megnézi a doctrine doksijait és megy is. Így olyan termék lesz a végeredmény amibe könnyebb fejleszteni, könnyebb megérteni.
- A hozzászóláshoz be kell jelentkezni
Mondom én, nem érted, hogy mit mondok.
Ha nem lenne nyelvi routing, csak semleges egységes, akkor is be kell töltenie egyszer azt is.
Hát ez az, de csak kellene az a nyelvi routing, amit ezidáig nem is tudtál máshogy megoldani (és nem is fogsz tudni, csak durva gányolás árán, mert alapból nem tud több route-ot).
Ugyanúgy betöltődnek az url-ek a framework alól, csak nem nyelvi verziók, hanem az amit te rewrite-val töltenél be.
Na de pont azt mondom, hogy rewrite-al dobd át a nyelvi verzióra. Ekkor a framework-nek már csak egyetlen egyszer kell betöltenie a routing-ot, és azt is már csak a nyelvkódos URL-hez, tehát egy route kell csak egy oldalhoz. Pont ez a lényeg, nem kell szétbarmolni hozzá a már meglévő Symfony routingot, azzal is működik.
Az admin felület alatt arra gondoltam, hogy ott szerkesztik alapból az url-eket és fordítják le.
Na, erre nincs semmi szükséged. A már meglévő URL szerkesztőt használod, nincs külön felület. Lekéred a már meglévő routing táblát az adatbázisból, kiegészítve az oldal nyelvfüggetlen alias-ával, végére biggyeszted, hogy "GROUP BY lang" és ennyi. Ezt írod a rewrite fájlba, match-nek az alias-t, célnak meg az URL-t. Az oldalhoz az alias-t bárhogy felveheted, bármilyen adatbázismezőben tárolhatod, nem kell belenyúlni a Symfony routingjába. Ha akarod, tárolhatod akár a routing táblában is nyelvkód nélkül, vagy sima oldal paraméterként, teljesen tök mindegy, a lényeg, hogy a Symfonyt nem kell átírnod hozzá.
Ha frameworkben dolgozol, akkor nem írunk fölé custom megoldásokat
Sosem beszéltem custom megoldásról! Pont azt mondom, hogy a Symfony 7 routing tábláját használod, épp csak előre kigenerálsz belőle egy rewrite-os "cache"-t, ami megoldja neked a nyelvek szerinti átpasszolást, hogy továbbra is elég legyen az egy route egy oldalhoz.
Ha egy másik fejlesztő belenézne a kódomba és meg akarná érteni,
Nem hiszem, hogy bármelyik másik fejlesztő boldog lenne, ha azt látná, hogy belebarmoltál a Symfony 7 framework alapértelmezett routingjába átírva a vanilla php kódot... Vagy hogy a rendszergazdátok repdesne az örömtől, hogy Symfony frissítés után mindig patchelgetnie kell.
Ha nem tetszik az ötlet, szíved joga, de azt lásd, hogy amit javasoltam, az bármilyen stock framework-el működik, garantáltan szopásmentes és jövőbiztos.
- A hozzászóláshoz be kell jelentkezni
Biztos, hogy PHP-val nagyobb az erőforrásigény, mint htaccessel? Még apacsban is ki lehet kapcsolni a htaccess értelmezését, mert lassít. Más webszervereken meg nincs is. A PHP meg már elég jól gyorsítja a kódot. Én nem látom a lényegi erőforráskülönbséget, de PHP route esetén a kód nem webszerverfüggő.
- A hozzászóláshoz be kell jelentkezni
Biztos, hogy PHP-val nagyobb az erőforrásigény, mint htaccessel?
Egészen biztos. De nyugodtan meg is mérheted.
Rewrite esetén egyszer felparseolja a szöveges fájlt, aztán felparseolt formában tárolja és helyben használja a memóriából a webszerver, semmilyen más erőforrásigény sem másik processzel való kommunikáció nincs a dologban. Ha rendesen van megírva, akkor a regexpeket is eleve felparseolt, tokenizált formában tárolja, és még Linux syscall hívásokra sincs szükség, helyben, a webszerver felhasználói memóriájában lerendez mindent.
Ezzel szemben PHP esetén:
1. össze kell állítani a php környezet a http fejlécek konvertálásával, query és post értelmezéssel stb.
2. php interpreter indulásának is van overheadje, potenciálisan másik processz, át kell neki adni a környezetet
3. a php-ból ki kell építeni a kapcsolatot az adatbázisszerver felé
4. az sql query-t át kell adni az adatbázisszervernek a kapcsolaton keresztül
5. a query-t a szervernek fel kell parseolni és tokenizálni kell (ezt mindig meg kell tenni, mert a query szövegesen érkezik a kapcsolaton keresztül)
6. a query-t le kell futtatni (külön lemezművelet, nem biztos, hogy az eredmény cache-elve van)
7. az eredményt át kell adni a php-nak a kapcsolaton keresztül
8. a php-nak a nyers kommunikációt át kell alakítania php változókká (jellemzően a db plugin és esetleg a PDO dolga)
9. az eredményt fel kell dolgozni php-ból (a tényleges Symfony routing)
Más webszervereken meg nincs is.
Minden webszerver tud rewrite-ot, direkt belinkeltem több dokumentációját is, hogy hogyan. A fenti mintám például nginx-es.
A PHP meg már elég jól gyorsítja a kódot.
Nem a php értelmezés a gyenge láncszem, hanem a rengeteg IPC, socket írás-olvasás (ezekhez rengeteg Linux syscallra és felhasználói-kernel memória közti másolásra is szükség van), no meg a különböző adatreprezentációk közti másolgatás és folyamatos konvertálgatás. A php interpreter elenyésző szelete csak a teljes overheadnek egy adatbáziskapcsolatot használó szkript esetén.
- A hozzászóláshoz be kell jelentkezni
Az 1-tők 9-ig minden pont lezajlik akkor is ha a te rewrite megoldásodat használja valaki -.- Ugyanúgy van routing, csak max nem 20 routingot tölt be, hanem csak 5-öt. Ugyanúgy van query, de mondjuk 2-vel kevesebb, bár mivel sf a routingot cacheli, így query sincs annyi.
Nem akarok végbebenő vitákba belemenni, nem látom értelmét. A lényeg, hogy értek mindent, hidd el, de nem tartom jónak az ötletedet több okból se.
- A hozzászóláshoz be kell jelentkezni
Az 1-tők 9-ig minden pont lezajlik akkor is ha a te rewrite megoldásodat használja valaki
Nem. Már mindjárt a legeslegelső pont se fut le a rewrite-os URL-re.
Ugyanúgy van routing, csak max nem 20 routingot tölt be, hanem csak 5-öt.
Nincs. A rewrite kizárólag a webszerver memóriájában történik.
Ugyanúgy van query
Nincs. A webszervernek egyáltalán még csak kapcsolata sincs az adatbázisszerverrel, hogy hajthatna akkor végre query-t?
A lényeg, hogy értek mindent, hidd el
Ez nem hit kérdése, pontosan tudom a válaszaidból, hogy nem értesz az egészből semmit sem. Mégegyszer: a rewrite a webszerver memóriájában történik, php és sql nélkül. A módosításához kell csak a Symfony, a sima oldallékéréshez nem, az egyből még a webszerverben átdobódik arra a nyelvkódot tartalmazó egyedi URL-re, amit egyébként is lekezelnél Symfony-ból.
Nekem mondjuk mindegy, gányold csak szét a Symfony-dat, de aztán ne lepődj meg, ha problémába ütközöl majd a frissítésnél és lassú lesz az egész.
- A hozzászóláshoz be kell jelentkezni
Ez nem hit kérdése, pontosan tudom a válaszaidból, hogy nem értesz az egészből semmit sem. Mégegyszer: a rewrite a webszerver memóriájában történik, php és sql nélkül.
Ha nem adatbázisból dolgozik a rewrite a webszerver oldalán, hanem statikusan fájlból, akkor nem ugyanaz a featureset, amiről beszéltek, a te megoldási javaslatod lényegesen kevesebbet tud nyújtani, ráadásul, ha a webszerver processze akar írni ilyen fontosságú konfigurációt, amibe szinte mindent bele lehet írni, az a melegágya a biztonsági problémáknak.
Nekem mondjuk mindegy, gányold csak szét a Symfony-dat, de aztán ne lepődj meg, ha problémába ütközöl majd a frissítésnél és lassú lesz az egész.
Látszólag te akarod szétgányolni, azzal, hogy minden kényelmi, biztonsági és framework szintű funkciót külön-külön megbaszol a teljesítmény oltárán. A helyzet viszont az, hogy az esetek nagyon-nagy részében a kutyát nem érdekli az, hogy mennyivel kevesebb CPU és memória lenne elég a kiszolgáláshoz, ha amúgy marginálisan kicsi a forgalma és egyébként is ott van a CPU és memória, kihasználatlanul.
Ahogy ugye a mondás szól: “Premature optimization is the root of all evil”.
- A hozzászóláshoz be kell jelentkezni
Ha nem adatbázisból dolgozik a rewrite a webszerver oldalán, hanem statikusan fájlból, akkor nem ugyanaz a featureset, amiről beszéltek, a te megoldási javaslatod lényegesen kevesebbet tud nyújtani, ráadásul, ha a webszerver processze akar írni ilyen fontosságú konfigurációt, amibe szinte mindent bele lehet írni, az a melegágya a biztonsági problémáknak.
Szerintem ez a legfontosabb, ami miatt aki kicsit is foglalkozott már webes rendszerek biztonságával, abban fel sem merül, hogy a webszerver (nopláne a php) processze írhassa ilyen szinten a saját konfigját (legjobb esetben leginkább semennyire sem). Szerintem a "melegággyal" még finoman is fogalmaztál, hosszú távon ezt én öntökönlövésnek tartom. Itt határozottan igaz, hogy a security és a performance egymás ellenségei. :)
- A hozzászóláshoz be kell jelentkezni
Én már nem akartam ebbe komolyabban belemenni, de természetesen megoldható, lightweight routingolás megírása. Rewrite átadja fullban az url-t és egy kvázi pár soros php script feldolgozza cache-ből. De oh wait, ezt a symfony pontosan így csinálja :)
Jelenleg az egyáltalán nem optimalizált rendszerem 7ms alatt lefutott localban, 4MB-os ram használattal.
Egyébként nginx-et használok webszervernek, amióta konténerekben dolgozom, és fpm-et használok azóta csak nginx-et tolom mellé.
- A hozzászóláshoz be kell jelentkezni
Ha nem adatbázisból dolgozik a rewrite a webszerver oldalán, hanem statikusan fájlból, akkor nem ugyanaz a featureset
Látom, Te sem érted. Két, egymástól független dologról van szó. Na mégegyszer:
1. amikor változik az URL, akkor egy Symfony-s php szkript lekéri a routingot az adatbázisból, és a nyelvkód nélküli URL-eket kiírja egy rewrite fájlba, mint amolyan cache-t. Ez csak akkor fut le, amikor VÁLTOZIK a routing.
2. az oldallekérés közben NINCS adatbáziskapcsolat, a nyelvkód nélküli URL-ek a webszerver memóriájában íródnak át nyelvkódos URL-ekké. Ez MINDIG lefut, de nem használ se php-t, se sql-t.
te megoldási javaslatod lényegesen kevesebbet tud nyújtani,
Francokat. Épp ellenkezőleg, lehetővé teszi, hogy egy oldalhoz több URL-t is fel tudj venni, amit jelenleg az OP nem tud vanilla Symfony-val megoldani.
amibe szinte mindent bele lehet írni
Miért is? A fájlba írást az Ő általa írt php végzi, az Ő általa admin felületen megadott adatokból. Ennyi erővel már az is gáz lehetne, hogy admin-ból egyáltalán megadható az URL, mert bármit bele lehet abba is írni.
Elfeledkezel róla, hogy nincs felhasználói adat sehol, csakis admin által biztosított adat kerül egy admin által készített template-be. Ha ez törhető, akkor az azt jelenti, hogy az egész admin felületük törhető...
Látszólag te akarod szétgányolni, azzal, hogy minden kényelmi, biztonsági és framework szintű funkciót
Miről beszélsz, miféle framrework szintű funkció? A Symfony alapból NEM is kezel több URL-t egy oldalhoz! Az én megoldásomnál NEM kell a Symfony kódjához hozzányúlni, a Ti megoldási javaslatotoknál ellenben igen, szétgányolás nélkül nem is implementálható Symfony-ba, amit akartok.
- A hozzászóláshoz be kell jelentkezni
Látom, Te sem érted. Két, egymástól független dologról van szó.
Pontosan ezt írtam én is: két külön dologról beszéltek.
Francokat. Épp ellenkezőleg, lehetővé teszi, hogy egy oldalhoz több URL-t is fel tudj venni, amit jelenleg az OP nem tud vanilla Symfony-val megoldani.
Egyrészt behozva egy csomó egyéb, jellemzően biztonsági problémát; másrészt meg tud oldani, csak neked nem tetszik az a megoldás, jössz mindig egy olyan megoldással, ami egy csomó körbetákolást igényel, hogy ránézésre biztonságos legyen, nemhogy valójában is.
Én a helyedben elgondolkodnék azon, hogy miért nincs a megoldási javaslatod benne egyik webes keretrendszerben se (vagyis az, hogy a webszerver rewrite rule fájlokat írja át röptében a PHP vagy egyéb framework), mert szerintem megint olyan dologba szólsz bele, amiről közel nulla tapasztalatod van...
- A hozzászóláshoz be kell jelentkezni
Ha nem adatbázisból dolgozik a rewrite a webszerver oldalán, hanem statikusan fájlból, akkor nem ugyanaz a featuresetLátom, Te sem érted. Két, egymástól független dologról van szó.
Pontosan ezt írtam én is: két külön dologról beszéltek.
Francokat, még véletlenül sem ezt írtad (direkt beidéztem azt is, amit írtál, hogy mindenki lássa). Még csak nem is arról volt szó, hogy mi miről beszélünk, hanem arról, hogy fingod sincs, miről szól a megoldásom.
Arról hordtál össze mindenféle baromságot, hogy "Ha nem adatbázisból dolgozik a rewrite a webszerver oldalán, hanem statikusan fájlból, akkor nem ugyanaz a featureset", ami nyilván nem igaz.
Amire én írtam, hogy "Két, egymástól független dologról van szó", az meg kizárlóag az EGYIK megoldás két komponensére vonatkozott, és még csak nem is a két megközelítésre, mint ahogy hitted!
Jól van fiam, egyes, leülhetsz.
- A hozzászóláshoz be kell jelentkezni
Még csak nem is arról volt szó, hogy mi miről beszélünk, hanem arról, hogy fingod sincs, miről szól a megoldásom.
Szerintem te nem érted, hogy mi a különbség. :)
Arról hordtál össze mindenféle baromságot, hogy "Ha nem adatbázisból dolgozik a rewrite a webszerver oldalán, hanem statikusan fájlból, akkor nem ugyanaz a featureset", ami nyilván nem igaz.
Pedig nyilván igaz, hogy nem ugyanaz a featureset, erre még te is rájöttél, mert elkezdted körbetákolni, különféle módosításokkal: cron, reload, külön fájl, ecetera. És még mindig nem néztük meg, hogy mivel véded meg a fájlt, hogy ne lehessen bele bármit írni, nem csak rewrite rule halmazt...
Jól van fiam, egyes, leülhetsz.
Tudod, magas lóról nagyot esni... :D
- A hozzászóláshoz be kell jelentkezni
LOL.
Jó kedvemben vagyok, ezért tételesen válaszolok a hülyeségeidre :-)
Szerintem te nem érted, hogy mi a különbség. :)
Senkit nem érdekel, hogy szerinted mi, amikor feketén-fehéren le van írva. Átlagos intelligenciával rendelkező egyének el tudják olvasni, sőt, meg is tudják érteni.
Hogy te nem tartozol ebbe a csoportba, az nem az én bajom.
Pedig nyilván igaz, hogy nem ugyanaz a featureset
Bizonyítsd! Mi az a feature ebben az esetben, ami nem megoldható, ha az adatbázis kimenetét használat előtt egy fájlban cache-eled!
elkezdted körbetákolni, különféle módosításokkal: cron, reload, külön fájl
Na ezzel alaposan beszaladtál tátott szájjal a faszerdőbe.Tanulj meg olvasni! Sehol semmi módosítás, ezeket már mind a legeslegelején leírtam. Sőt, a cron-ra is utaltam már az első válaszomban. Ott áll feketén fehéren, az nem az én bajom, hogy nem tudsz olvasni.
Jól van fiam, egyes, leülhetsz.
- A hozzászóláshoz be kell jelentkezni
Te mostanában nagyon szeretsz tátott szájjal a faszerdőben szaladgálni. :D
Tényleg javaslom, hogy ül le és gondolod egyszer végig, hogy vajon miért nem használja egyik elterjedt keretrendszer sem az általad javasolt megoldást. Vagy mindenki balfasz, akinek ez a fő szakterülete vagy te vagy balfasz ehhez a területhez és a problémák töredékét se látod át.
- A hozzászóláshoz be kell jelentkezni
Bocs, de lehet több url-t felvenni egy "oldalhoz", azaz egy controller alatti method-hoz. Tökéletesen működik.
A symfony kódjához amúgy se kell hozzányúlni, hisz a symfony kódját a vendor alatt nem szerkesztjük.
Sajnos jól mondják, totál szétgányolnád a rendszert olyan megooldással ami lényegében megoldható a fw alatt.
Nekem az a gyanúm, hogy fingod nincs se a php se a symfony működéséről/használatáról. Mintha el se olvasnád amit írunk, vagy nem is értenéd.
- A hozzászóláshoz be kell jelentkezni
Te írtad:
Nagyon sok doksit átolvastam, átnéztem fórumokat. Nem jöttem rá hogy kéne felvinni több routingot egy name alatt több nyelven.
Én erre, és csakis erre adtam egy olyan működő megoldást, amihez nem kell belenyúlni a Symfony kódjába.
Sajnos jól mondják, totál szétgányolnád a rendszert olyan megooldással ami lényegében megoldható a fw alatt.
Ha megoldható, akkor meg mi a fészkes fenének indítottad ezt az egész topikot???
Aki pedig azt hiszi, hogy ha hozzá sem nyúl a kódhoz, azzal "szétgányolná a rendszert", az már bocs, de hülye. Pont az a lényeg, hogy nem nyúlsz a framework kódjához, vanilla Symfony-val működik, így garantáltan jövőbiztos. Ha valóban "szétgányolná a rendszert", akkor nem lehetne jövőbiztos, ugyebár.
- A hozzászóláshoz be kell jelentkezni
Ha nem értesz a keretrendszerhez, akkor érthető, hogy nem érted meg a kifejezéseket, kulcsszavakat se. Ez nem baj, de akkor ne írj rá tanácsot.
A routing name nem az adott controller methodja tehát a cél amit bedrótozol egy url alá, hanem az adott routing named id-je.
Ha azt mondod, hogy van egy routingod, annak adhatsz egy nevet amire hivatkozhatsz.
Továbbra is félrebeszélsz. A te htaccess-ed se írja meg saját magát. Azt is implementálni kell a kódban.
Nem az a "jövőbiztos", hogy kikerülöd fw-t és nem dolgozol vele, hanem az, ha folyamatosan frissen tartod a vele írt kódodat és frissíted, karbantartod.
- A hozzászóláshoz be kell jelentkezni
Továbbra is félrebeszélsz. A te htaccess-ed se írja meg saját magát. Azt is implementálni kell a kódban.
Nem én beszélek félre. Nem beszéltem htaccess-ről se (az eredeti posztomban konkrétan nginx példa díszeleg, még csak nem is apache-os). És nem beszéltem Symfony framework kód módosítás implementálásáról se.
Az én javaslatom a már meglévő Symfony kódbázis mellett (és nem pedig azt módosítva) implementálandó, de minek is magyarázom?
Nem az a "jövőbiztos", hogy kikerülöd fw-t és nem dolgozol vele
Nem kerülöm ki. Csak cache-elem az fw kimenetét egy olyan formátumban, amit történetesen csont nélkül megeszik a webszerver. De úgysem érted, hiába.
- A hozzászóláshoz be kell jelentkezni
Jah és mégegy, nem a Symfony -ról szólt a topic, hanem a ChatGPT-ről. Senkitől se vártam Symfony-s tanácsokat.
- A hozzászóláshoz be kell jelentkezni
Te írtad:
Nagyon sok doksit átolvastam, átnéztem fórumokat. Nem jöttem rá hogy kéne felvinni több routingot egy name alatt több nyelven.
- A hozzászóláshoz be kell jelentkezni
Így van, ezt írtam. Ebből hol olvastad ki, hogy nem kezel szerintem a Symfony több url-t egy "oldalhoz" és hol láttad azt, hogy Symfony/php tanácsra várok?
- A hozzászóláshoz be kell jelentkezni
Ezt most komolyan kérded? Tényleg azon lovagolsz, hogy a "name-el ellátott egyedi routing céljául megadott controllerrel rendelkező" helyett egyszerűen "oldalt" írtam? Ha nem értetted, akkor nem velem van a baj, bocs.
A "nem jöttem rá hogy lehetne" magyarul azt jelenti, hogy nincs megoldásod, és mivel ezt egy olyan IT fórumra írtad ki, ahol kérdezni szoktak... (Ráadásul a Fejlesztés kategóriába).
- A hozzászóláshoz be kell jelentkezni
Befejeztem a vitát.
- A hozzászóláshoz be kell jelentkezni
Vita nem is volt. Nézd, én csak tippet adtam, hogy hogyan kell hatékonyan megoldani azt, amivel küzdesz, te meg nem értetted, mert eggyel alacsonyabb rétegben van megvalósítva, mint amihez értesz.
Ha nem érted, hogy a rewrite-ot pontosan ennek a problémának a hatékony megoldására rakták bele a webszerverekbe, arról nem tehetek, az már nem az én bajom.
- A hozzászóláshoz be kell jelentkezni
Azt ugye vágod, hogy a rewrite mögött ugyanaz a symfony lenne és nem egy statikus html?
- A hozzászóláshoz be kell jelentkezni
Nem vagyok tapasztalt az ngix működésében, de úgy tudom, nem tudja azt a funkciót, amit a .htaccess, azaz, hogy a mappába bemásolt fájlt a kérelem idején olvassa és értelmezi. Amennyiben a webszerver konfigurációjában kell beállítani a rewrite-ot, az valóban elég hatékony lehet, de azt meg a php nem fogja tudni legenerálni. (Vagy legenerálja, de nem tudja felolvastani a webszerverrel.)
A .htaccess esetén pedig nem csak felolvassa a fájlt és értelmezi, hanem minden kérelem esetén a gyökérkönyvátrtól egészen kiszolgáló mappáig minden mappát át kell néznie, és el kell döntenie hogy van-e ott .htaccess, módosult-e, és ha igen értelmezni is a tartalmát. Azt nem tudom, tárolja-e a htaccess-ekben lévő szabályokat, vagy kérelmenként értelmezi, a forrást még sosem láttam.
- A hozzászóláshoz be kell jelentkezni
Így van, kell az nginx-nek egy signalt küldeni, hogy újraolvassa a konfigot. Ezt csak az admin teheti meg.
Konfigot egyébként nem írhat a php, csak egyetlen egy fájlt, amit a megfelelő helyen include-ol az nginx konfig, és azt az egyetlen egy fájlt is csakis admin által biztosított adatokból generálja.
De ha valaki nagyon nagyon biztonságosra akarja megcsinálni, akkor cron-ból percenként futtatható egy szkript, ami megnézi, változott-e a Symfony routing (sima timestamp check), és ha igen, akkor újragenerálja a rewrite konfigot és küld egy signalt az nginx-nek. Ekkor sem a fájlt író szkript, sem a létrehozott fájl nem lesz a webszerver user nevében. Az egyetlen hátránya ennek a megoldásnak, hogy URL módosítás után várni kell max. 1 percet, mire érvénybe lép, viszont atombiztos (mert nem is a webszerver futtatja a rewrite generálót).
- A hozzászóláshoz be kell jelentkezni
Egy átlagos osztott környezetben felhasználóként nincs módod befolyásolni a webszerver működését. Ez a megoldás csak akkor jöhet szóba, ha a teljes szervert a PHP kód készítője üzemelteti. Ez szerintem azért a ritkábbik eset. Gyanítom ez az egyik oka annak, hogy a Simphony is a PHP routingot támogatja, hogy minden környezetben működhessen.
- A hozzászóláshoz be kell jelentkezni
Valahogy így gondolom én is, ez a symphony-revproxy oda-vissza kooperáció csak egy monolit környezetben, nagyjából csak "single instance" esetében működhet jól.
Se nem túl biztonságos, se nem túl üzembiztos/konzisztens egy elosztott-clusteres környezetben.
Érdemes a layereket (felelősségeket, határokat) tisztán és egyszerűen tartani még akkor is ha ez néhány CPU ciklussal többe kerül adott esetben.
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni
Olyan, mint egy junior, csak közben azt hiszi magáról, hogy senior... ja, várj, olyan, mint egy junior... :D
- A hozzászóláshoz be kell jelentkezni
Programozóként Geminit használom inkább. Kódot írni az se nagyon tud, viszont egészen jól kiváltja a hosszas guglizásokat és többnyire releváns linkeket ad összefoglalóval együtt. Tipikus iskolapéldákat különben sokszor jól hoz mind a kettő, de az nem programozás, csak minták visszaböfögése.
- A hozzászóláshoz be kell jelentkezni
igazából gpt is úgy kiadta nekem a példakódokat mintha most nyalta volna be a doksikból. Totál hülyének nézett.
Esküszöm, azoknak való akik nem képesek googlezni. Bár ott mondom az a gond, hogy meggyőzően átveri azt aki nem ért hozzá.
- A hozzászóláshoz be kell jelentkezni
Gyorsabb a google-nel.
- A hozzászóláshoz be kell jelentkezni
Pontosan.
Tegnap pl. egy konkrét célra kerestem egy library-t. Régebben órákat töltöttem volna a 80 alternatíva doksijainak bogarászásával, most viszont leírtam Gemininek a pontos igényeimet, javasolt 4-et, amiből 3 "ágyúval verébre" megoldás lett volna, viszont az egyik szinte semmivel sem tud többet, mint ami nekem kell, totál minimál megoldás és nagyon egyszerű. Kb 5 perc volt eldönteni, melyiket fogom használni.
- A hozzászóláshoz be kell jelentkezni
Távolról kapcsolódik...
https://x.com/ctjlewis/status/1791412663408332853
https://x.com/aishvarr/status/1791422495641285066
Meg hát ugye:
- A hozzászóláshoz be kell jelentkezni
An AI walks into a bar. The bartender asks, "What can I get you?"
The AI replies, "I'll have what everyone else is having."
Innen másoltam be, de a Brian Lunduke gyűjteményében láttam először: https://www.reddit.com/r/ChatGPT/comments/1bpkv2n/tell_me_a_joke_about_…
- A hozzászóláshoz be kell jelentkezni
elkurvitott az x? :(
- A hozzászóláshoz be kell jelentkezni
Persze, ezt írom én is mindig, nem veszi el az AI a fejlesztők munkáját. Nem alkalmas arra, hogy tuti működő és megbízható kódot írjon. Arra jó, amire most te is használtad, nem volt ölteted, megkérdezted az AI-t, az vázolt valamit, ami arra lehet jó, hogy irányt keress, ötletet, merre indulj el. Megcsinálni nem fogja senki helyett, ezt csak a média, meg a marketingesek akarják mindenkinek bemesélni, meg az NVidia, hogy eladhassa az AI-hoz a túlárazott, méregdrága GPU-it.
Épp úgy nem váltja ki az AI a fejlesztői munkát, ahogy a gépi fordítók se váltották ki soha a tolmácsokat, fordítókat, nem tették mellőzhetővé a nyelvtanulást, stb.. Az AI persze hasznos, de csak egy segédeszköz, mint egy jó IDE, debugger, language server, stb.. A világot nem váltja meg önmagában.
Amire nagyon jó, az az ötletelés, ihletkeresés, pl. ha valami dizájn, logó, vizuális megvalósításhoz keres valaki ötletet, vagy pl. nagy mennyiségű statisztikai adaton tanítja be az AI-t, hogy korrelációkat keressen bizonyos tényezők között, pl. orvosi felvételeken daganatokat szoktak vele kerestetni, persze kutatási anyagban, hátha lát összefüggést utólag. Ilyenre kiváló.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Épp úgy nem váltja ki az AI a fejlesztői munkát, ahogy a gépi fordítók se váltották ki soha a tolmácsokat, fordítókat, nem tették mellőzhetővé a nyelvtanulást, stb.
Bizony!
- A hozzászóláshoz be kell jelentkezni
A fejlesztés az túlzás, de powershell, bash, python scripteket, ansible, cloudformation, terraform templateket, hasonlókat simán iratok vele.
Van hogy néha félremegy amit generál, hülyeséget csinálna, félreért vagy kitalál nem létező funkciókat, ez tény. De legalább ad egy használható megoldás vázlatot hogy hogyan is kéne kinézzen a működő kód.
Ahol viszont logikára, tervezésre, összetett gondolkodásra volna szükség, azt nem érdemes egyben megpróbálni vele. Azt még nem tudja mint egyszerű nyelvi modell.
De apróbb részletekre lebontogatva a bonyolult feladatokat nagyon jól lehet vele haladni. Szerintem az a gond hogy sokan egy kész feladatleírást bevágnak neki, aztán csodálkoznak hogy hülyeség jön ki a végén.
"Everything fails, all the time."
- A hozzászóláshoz be kell jelentkezni
> Persze nála gyorsabban megvoltak a válaszok
ez a lenyeg... nyilvan az AI elott is lehetett guglizni, forumokban keresni/kerdezni stb, de az AI az osszeset elolvasta mar es vagja a valaszokat, jot is rosszat is, epp mikor mit dob a VELETLENBGENERATOR.
> Azt nem értem, hogy valóban emberek fejlesztenek vele?
allitolag igen. es allitolag a fizetos gpt 4.x jobb, mint az ingyen elerheto 3.5-os
- A hozzászóláshoz be kell jelentkezni
https://chatgpt.com/share/38864043-5132-497a-a6f2-0c4e762362e2
Ezt GPT-4 -el sikerült elérni, ami fizetős. Nem mindig ad helyes választ, és símogatni kell a lelkét (rávezetni a helyes megoldásra), hogy kifacsarjon az ember belőle értelmes választ.
( Feltéve, hogy van ehhez valakinek cérnája )
De van amikor ez sem segít, és bekamuzik valami baromságot:
https://chat.openai.com/share/b59ff260-1d04-494b-bf23-90dab234dbda
<artifactId>spring-ai-starter</artifactId>
^ No persze.
Amit viszont hasznosnak találtam az a Bito Ai Code Assistant IDEA -hoz. (Van VSCode -hoz is)
- A hozzászóláshoz be kell jelentkezni
es allitolag a fizetos gpt 4.x jobb, mint az ingyen elerheto 3.5-os
Hat jobbnak tenyleg jobb, de egyelore a "fejlesztenek vele" az azt jelenti, hogy megetettem vele egy-egy temaban az osszes doksit, amit meg tudtam szerezni ertelmes formaban, aztan tudok tole kerdezni, es valaszol. Valamit. Gyakran egesz jot, raadasul, de azert a bugot nem javitja meg, amivel kapcsolatban kerdezek tole.
- A hozzászóláshoz be kell jelentkezni
opensource libraryk hasznalatanak megertesere sokkal gyorsabb mint guglizni, multkor kb 1 ora beszelgetesbol hasznalhato kliens/szerver part kodolt le nekem ugy, hogy azt csinalta amit akarok, olyan libraryben, amit eletemben nem hasznaltam :)
- A hozzászóláshoz be kell jelentkezni
Hasonlo, csak hasznalt kozben 3 olyan metodust, ami sosem letezett, es valtig allitotta, hogy az egy built in az open source libben. Persze az ilyesmi is konnyen workaroundolhato. :)
- A hozzászóláshoz be kell jelentkezni
A CodePilot eléggé berobbant, a chatgpt chatablak messze nem a legoptimálisabb felület komolyabb felület támogatására, és akkor még finoman fogalmaztam. Egy újabb eszköz a szerszámosládában, hozzáértők kezében jelentős produktivitás emelkedés érhető el, aki meg nem tud programozni, azon meg ez se segít. Szakértelem és szorgalmas munka nélkül ugyanis nem lehet értéket teremteni nyelvi modellel sem, bármit is hordanak össze a marketingesek.
Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.
- A hozzászóláshoz be kell jelentkezni
En Power Apps -hoz hasznalom. Leginkabb abban tud segiteni, hogy megertsek egy uj funkciot. De az elo magusoktol lehet igazan sokat tanulni. Es azert eleg sokszor ordas nagy baromsagokat tud irni.
- A hozzászóláshoz be kell jelentkezni
Fejleszteshez nem hasznalom, de mondjuk copywrite placeholder szovegek legeneralasahoz UI-hoz igen, lorem ipsum helyett
Nyelvi model, igy ajanlott akkent is kezelni.
- A hozzászóláshoz be kell jelentkezni
Excel automatizálást kellett írnom kollégáknak, 90%ban megírta a basic kódot a maradékhoz egy kis Google kellett. A lényeg hogy 10 perc alatt megoldódott az egész.
- A hozzászóláshoz be kell jelentkezni
Azon is sok múlik, hogy melyik AI-t kérdezed. A GPT-3 turbó, és a 3.5 általában csak a legegyszerűbb feladatokkal birkózik meg, míg mondjuk a GPT-4 komplett funkciókat megvalósít egész jó minőségben.
Nyilván a rendszer logikájának a kitalálását ne hagyd rá, de mondjuk ha megkéred, hogy nézze át a kódodat biztonsági vagy optimalizálás szempontjából, néha nagyon jó ötleteket ad.
Nagy Péter
- A hozzászóláshoz be kell jelentkezni
Igen, fejlesztenek. én is használom. seniorként kifejezetten hasznos hogy egy csomó boilerplate-t megír nekem. a hülyeséget kiszúrom / úgyis tesztelem.
Amikor valami új dologba kezdek kifejezetten hasznos hogy sokezer oldal doksi elolvasása helyett csak felteszem a kérdést és jól válaszol.
Nem "okos kreativitást" kell elvárni tőle hanem nagy tömegű információ gyors és jó összefoglalását, keresését.
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni