Adott egy mvc alapu webes gui, ahol a view-ban php valtozok, ciklusok, stb. vannak. Arra gondoltam, mi lenne, ha kidobnam belole a php elemeket, es az tisztan html+javascript lenne.
A view-kban olyan php valtozok is vannak, amelyek erteke egy adott szo egy adott nyelven, pl.
<?php print $text_submit; ?>
ami azt irja ki, hogy "Submit" vagy "Elkuld", stb. a beallitott nyelvtol fuggoen.
A kerdes pedig az, hogy lehet szepen megoldani azt, hogy ezek a nyelvtol fuggo html reszek a php kidobasa utan is korrektul jelenjenek meg?
A masik kerdes pedig az, hogy van egy javascript file-om, aminek egy php-ban beallitott (config.php) valtozot is at kellene adni (hogy a datepicker a megfelelo nyelven mutassa meg a honapok nevet). Hogy lehet ezt megcsinalni?
- 5915 megtekintés
Hozzászólások
1. Nem értem, miért akarod kidobni a php-t... De ha kedved tartja, akkor megteheted, csak nem tudom hogyan fogod átvinni a változókat html-be, javascript-be... Pont erre (is) jó a PHP...
2. Én .htaccess-t bizergálnám és pont a PHP-t alkalmaznám arra, hogy egy paraméter alapján készítse el a szkriptet... :D
Mesélj még ezekről a dolgokról és talán jobban tudok segíteni :D
--
Debian Linux rulez... :D
- A hozzászóláshoz be kell jelentkezni
2. Én .htaccess-t bizergálnám és pont a PHP-t alkalmaznám arra, hogy egy paraméter alapján készítse el a szkriptet... :D
Az elso gondolatom nekem is ez volt: script type="text/javascript" src="..../javascript.php" :-)
1. Nem értem, miért akarod kidobni a php-t.
Az otlet onnan jott, hogy kaptam egy fulest, miszerint az jo(bb) lenne, ha nem szerver oldali templating lenne, hanem kliens oldali, mert akkor enterprise kornyezetben konnyen at lehetne irni a gui-t, pl. mobil klienst csinalni, stb. ill. az egesz webes resz is konnyebben atirhato lenne egy hatekonyabb nyelvre, pl. java, stb. ha a view-ban nincsenek php reszletek.
De nem akarom feltetlen kidobni, csak ha jobb az uj megoldas.
- A hozzászóláshoz be kell jelentkezni
Akkor mar valamifele API-t irnek a rendszerhez, utana YUI, ember.js, backbone.js, stb.
- A hozzászóláshoz be kell jelentkezni
nem egeszen ertelek, egy kicsit bovebben is kifejtened?
- A hozzászóláshoz be kell jelentkezni
Én sem értem miért akarod kidobni a PHP-t a view rétegből, a kliens oldali template-ezéssel csak feleslegesen terheled a kliens gépét ami egy nagyobb webapp-nál akár annak akadázosát is okozhatja.
Amire a kolléga utalt felettem:
írsz egy API-t ami nem csinál mást mint visszaadja a kért adatokat JSON-ban vagy XML-ben. Letöltődik az oldal a user gépére, Javascripttel, mindennel együtt, majd Javascriptből hívogatod az API megfelelő metódusait, ami visszaadja az adatokat, majd ezeket Javascript-ben kirakod (kliens oldali template-ek, miegymás). A PHP-ból beálított változó értékét is így tudod megoldani, Javascript-ből meghívod a http://webappod.hu/api/getLocale metódust, ami visszaadja neked a számodra szükséges változót.
Szvsz csak feleslegesen szivatod magad, lassítod az alkalmazást és a fejlesztést is. Ezen kívül a biztonságra is jobban oda kell figyelned, egy plusz webes API csak felesleges támadási felületet jelenthet.
"Az otlet onnan jott, hogy kaptam egy fulest, miszerint az jo(bb) lenne, ha nem szerver oldali templating lenne, hanem kliens oldali, mert akkor enterprise kornyezetben konnyen at lehetne irni a gui-t, pl. mobil klienst csinalni, stb. ill. az egesz webes resz is konnyebben atirhato lenne egy hatekonyabb nyelvre, pl. java, stb. ha a view-ban nincsenek php reszletek."
Ha már át akarod/akarjátok írni más nyelvre, akkor a view-ban lévő pár PHP echo lesz a legkevesebb.
- A hozzászóláshoz be kell jelentkezni
nem annyira nagy az app, max. ~1kB json adatot kell prezentalni a kliens fele
A PHP-ból beálított változó értékét is így tudod megoldani, Javascript-ből meghívod a http://webappod.hu/api/getLocale metódust, ami visszaadja neked a számodra szükséges változót.
ez tetszik!
Ezen kívül a biztonságra is jobban oda kell figyelned, egy plusz webes API csak felesleges támadási felületet jelenthet.
hacsak nem neztem be nagyon valamit, akkor arra gondoltam, hogy a json adatokat ajax hivason keresztul kapnam meg, amit a lentebb irt jquery pluginnel prezentalnek a kliens fele. A biztonsag kapcsan a kulonfele jogosultsag ellenorzesek, stb. szerveroldalon, a php scriptekben van megoldva. Elvileg a kliensoldali osszetevoket (html, javascript) kedvedre manipulalhatod, de nem latsz tobbet, mint amit a szerveroldali komponensek megengednek.
Ha már át akarod/akarjátok írni más nyelvre, akkor a view-ban lévő pár PHP echo lesz a legkevesebb.
jogos.
- A hozzászóláshoz be kell jelentkezni
Egyet ertek a felettem szoloval, es igen, arra gondoltam.
Ha már át akarod/akarjátok írni más nyelvre, akkor a view-ban lévő pár PHP echo lesz a legkevesebb.
Ha nem cel a kulonbozo mediumok/platformok tamogatasa, akkor felesleges, sot, egyenesen rossz atterni kliens oldalra. JS mindig lassabb lesz DOM muveletek kapcsan, mint egy kesz html dokumentum, amit esetleg utana modositasz minimalisan js-el
Szoval ha csak a szetvalasztas a cel, akkor a php-t rendezd at. Ha a cel az (is) hogy kesobb mobil platformon, funyiron, hutogepen is lehessen futtatni a cuccost, akkor jogos lehet, de akkor is erdemes merlegelni, hogy az adott platform elbirja-e, es nem egyszerubb-e egy pl android eseten webview-re bizni a dolgokat.
- A hozzászóláshoz be kell jelentkezni
Ha nem cel a kulonbozo mediumok/platformok tamogatasa
a szamitogep az elsodleges platform.
JS mindig lassabb lesz DOM muveletek kapcsan, mint egy kesz html dokumentum, amit esetleg utana modositasz minimalisan js-el
a gyors mukodes alapveto. Bar szerintem (mivel a tortenesek 1 oldalon vannak, azaz nem 2 km hosszan scrollozhato adatokat mutatok a felhasznalonak) talan nem lenne veszes, ha az adatok kliens oldalon lennenek renderelve.
Ha a cel az (is) hogy kesobb mobil platformon, funyiron, hutogepen is lehessen futtatni a cuccost
A mobil platform esetleg szoba johet (majd kesobb), de arra gondolom, egy spec. app meg jobb lehet. A webview-t elrakom a fejembe, kossz.
- A hozzászóláshoz be kell jelentkezni
A .htaccess-re nekem valami ilyen nyalánkság ugrott be:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^js/(.*)$ javascripteloallito.php?p=$1 [QSA]
A szkriptben meg egy jó kis header('Content-Type: text/javascript');
A kliens oldali templating-et hogy fogod megoldani? Javascript? És ha le van tiltva?
Én fázok az ilyenektől...
--
Debian Linux rulez... :D
- A hozzászóláshoz be kell jelentkezni
A .htaccess-re nekem valami ilyen nyalánkság ugrott be:
teljesen igazad van :-) igy fogom csinalni.
A kliens oldali templating-et hogy fogod megoldani? Javascript? És ha le van tiltva?
a javascript kell a kliensen, mert jelen allapotban is eleg masszivan epitek a jquery-re. Anelkul bela be tud lepni, es kb. ennyi. A kliens oldali template eseten a microsoft (khmm, khmm :-)) jquery.tmpl.js cuccara gondoltam.
- A hozzászóláshoz be kell jelentkezni
Anno én azt csináltam, hogy a login form onSubmit kezelőjére akasztottam egy függvényt, ami lényegében a jelszó mező tartalmára ráengedett egy md5-öt (a sessionhöz tartozó egyedi salt-ot használva). Ez három kellemes hatással járt: a szerveren nem jelent meg a jelszó plain textben (jelszócserénél sem), js nélkül belépni sem lehetett, és a talán legfontosabb: hiába mentette el a jelszót az user, a mentett jelszóval már nem tudott belépni (hiszen a hash függvény kimenete lett mentve).
- A hozzászóláshoz be kell jelentkezni
nice. Btw. pontosan mit vetsz ossze a szerveroldalon tarolt sozott cryptelt jelszoval?
- A hozzászóláshoz be kell jelentkezni
A szerveren a jelszó md5 kivonata volt tárolva, sózás nélkül (külön sémában, a webes sémából csak néhány tárolt eljárás érte el) - ez is bőven jobb volt, mint az azt megelőző plain text tárolt jelszóval megvalósított login...
Ha jól emlékszem, valahogy úgy csináltam, hogy a kliens ip-címe plusz egy süti mellé tároltam a szerveren egy random saltot, ezt a login form-ban egy hidden mezőben megkapta a kliens, és a jelszó mezőt onSubmit-tal md5(userid|salt|md5(jelszo)) -ra cserélte. A szerveren megvolt a süti, a form-ból érkező salt, az userid, meg az előbbi login hash, illetve egy táblában az userid md5(jelszó) összerendelés.
Süti+felküldött salt és a kliens ip-címe alapján a salt ellenőrizhető, utána a userid-hez tárolt md5(jelszo) előszedésével a szerver is csinált egy md5(userid|salt|md5(jelszo)) -t, és ha a klienstől érkezővel azonos volt, akkor rendben volt a dolog, kapott a user egy session meg egy tranzakció sütit, és a további oldalak már azokat vizsgálták.
A jelszócsere meg a régi jelszó ismeretében ment csak, ott valami md5(md5(régi_jelszó)|salt|md5(új_jelszó)) került elküldésre - az onSubmit-ban a form régi_jelszó mezőt felülírva valamivel, hogy az a hash se menjen át a hálózaton. Az első jelszót sms-ben kapták, azt meg első login során egy flaget figyelve le kellett cserélni.
Régen volt (bő tíz éve), a fene sem emlékszik pontosan rá, de nagy vonalakban valami ilyen volt.
- A hozzászóláshoz be kell jelentkezni
kossz a reszleteket. 10 eve meg lehet eleg volt siman md5 hash-t tarolni, de valamelyik soc. media site-nak nagy problemaja volt nem olyan regen, mert nem soztak a tarolt jelszavakat. Bar a plain text-nel azert jobb :-)
- A hozzászóláshoz be kell jelentkezni
A jelszótárolás külön sémában volt, a webes sémából csak néhány faék egyszerű tárolt eljáráson keresztül lehetett hozzáférni (a fentebb vázolt, böngészőből érkező userid és hash jó/nem jó, illetve userid, jelszócsere hash esetén sikeres/sikertelen a jelszó cseréje).
- A hozzászóláshoz be kell jelentkezni