PHP+Javascript+Böngészők

Internet: PHP, CGI, stb.

Sziasztok!

Adott az alábbi kódrészlet PHP-ben:
if (empty($_POST['name'])) {
$name_valid=false;
echo "< script type=\"text/javascript\" >";
echo "alert('A Név mező üres! Kitöltése kötelező!');";
echo "< /script >"; (itt szándékosan szóközösítettem a script tageket)
} else {
$name_valid=true;
}

Google Chrome alatt működik is: ha a Név mezőt üresen hagyom, kiteszi az alert-et. Ám Firefox és Opera alatt viszont már nem. Simán tovább megy...

Ti értitek ezt, miért van? Mit rontottam el?

Előre is köszönöm a segítséget.
Üdv,
gkaroly

  • 1350 megtekintés

( deje | 2011. 07. 15., p – 14:38 )

Bocs, hogy kukacoskodok, de miért a submit után dobsz fel alert()-et? Én így csinálnám:

  • submit után ha vmi nem stimmel akkor inkább vissza a form-ra, és jól láthatóan megjelölni a hibás mezőket, plusz globális hibaüzenet pirossal
  • opcionálisan a formon az onsubmit eseménynél megnézni, hogy minden oké-e, még submit előtt, és alert() vagy színezés

Én személy szerint útálom a felugró ablakokat, és tapasztalataim szerint sok ember simán rákattint az OK-ra egy ilyenen anélkül, hogy elolvasná mi a nyavaja volt az.

( redman | 2011. 07. 15., p – 14:37 )

Nekem megy firefox alatt is. De miért ne menne? Hiszen ez nem kliens oldali probléma.
Ha egy form-ot POST-olsz előtte, akkor nem lehet, hogy a name mezőben benne marad van valami:

Esetleg próbáld meg így:

if (trim($_POST['name'])==""){
}

http://www.redman.hu

Na miért? Mi a baj? Javíts ki, ha már azt mondod, hogy hibás.

valahogy így kéne írnom?

if (isset($_POST['name'])){

if (trim($_POST['name]=="")){

/*Ide meg jön a javascript*/

}

}

A debug-hoz az egyszerűbb változat is elég.
Egyébként én még az else ágba is beletennék valami jelzőt, hogy abba mikor fut bele.

http://www.redman.hu

( Aadaam v | 2011. 07. 15., p – 15:46 )

Na, ez az, amit nem csinalunk.

Ugy is mondhatnam,

________                ___     ____
    |       |    |     /   \   /     
    |       |    |    |     |  \___
    |       |    |    |     |  `   \
    |       |    |____ \___/   \___/

  • Nem gyartunk javascript utasitasokat php-bol
  • Nem gyartunk script tageket, plane nem sokat egymas utan
  • Nem kommunikalunk scriptgeneralassal szerver es kliensoldal kozott

Hogy miert nem megy, az innentol kezdve reszletkerdes, ha webbel akarsz foglalkozni (vagy nem akarsz, de fogsz) akkor errol szokj le.

Amit te akarsz csinalni, arra a tipikus pattern a notification area.

Eloszor is dontsd el, elso hibanal lepsz ki, vagy minden hibat kiirsz.

Ha elso hiba, akkor eleg egy string, egyebkent vegyunk fel egy tombot:

$hibak = array();

Na ha valami hiba tortenik, akkor beleirunk:

$hiba[]= "Nem toltotted ki a nev mezot";

Eloszor elvegezzuk az ellenorzest, es ha nem volt hiba (a hiba tomb hossza 0) akkor hajtunk vegre adatbazismuveletet:

if (count($hibak) === 0) {
//adatbazisba iras
}

A hibakat pedig berakjuk egy divbe. Erre erdemes lenne valami templating-et hasznalnod, de kiirhatod egybe is:

echo '< ul class="hibak">';
foreach ($hibak as $hiba){
echo '<li>'.$hiba.'</li>';
}
echo '</ul>'

es css-bol a hibak-at pirosra szinezed:
.hibak {
border:1 px solid red;
background-color:pink;
}

peldaul.

Ennel vannak 100 000-szer szofisztikaltabb megoldasok (ajax-bol elkuldod, visszajon egy JSON szerkezet, ami elmagyarazza a hibakat, stb),de elsore ez talan megteszi.

Annyival kiegészíteném a dolgot csak a tisztánlátás végett, hogy kétféleképpen tudsz validálni. Kliensoldalon, illetve szerveroldalon. Ebből az egyik kötelező a másik opcionális. Gondolom nem árulok el titkot azzal, hogy a szerveroldali validálás a kötelező/fontosabb, mert ha nincs bekapcsolva az illetőnél a JS támogatás akkor nem sokra mész a kliensoldali csekkolással. Én viszont azt ajánlom, hogy mind a két módszert használd, mivel ha már kliens oldalon kiszűröd a hibát akkor megspórolsz egy szerver oda-vissza kommunikációt, nem kell újratölteni az oldalt meg amúgy is elegánsabb dolgokat tudsz kihozni.

Amit Aadaam írt az jó lesz szerver oldalra, de ha a felhasználónak van JS támogatása és jól megírod a kliensoldali validálást, akkor odáig sosem fog eljutni.

Egy tipp a kliens oldali részre: Használj valamilyen libet (jQuery pl), mert sokkal könnyebben tudsz majd dolgozni, bár ha nem jól használod akkor nagyon le tudod húzni a teljesítmény, de ezt majd kitapasztalod.

Első körben mondjuk lehetne egy olyan hogy végig iterálod a form inputjait és végig nézed az értékeket. Vagy ha jó szelektort használsz akkor még iterálnod sem kell.

Igen, akkor egy un. template-valtozot kell felvenned.

A template valtozo az olyan mint a Word korlevel, ez a Kedves holgyem/uram helyett a Kedves Katalin, mint Kedves %username%.

A template nyelvekrol Parr irt egy jo cikket (Enforcing Strict Model-View Separation in Template Engines), hogy konkretan a Joomla mit csinal, azt sajnos nem tudom neked megmondani, de rendszerint ketfele valtozo mindig letezik:

- Az egyik egy existence valtozo, amivel el lehet donteni, valami igaz vagy hamis (jelen esetunkben ennek eloallitasa a $megkelljeleniteniahibadivet = (count($hibak) === 0) koddal lehetseges)
- A masik egy ertekvaltozo ami rendszerint string. Ennek eloallitasara egyszeruseg kedveert az echo helyett felveszunk eloszor is egy

$hiba_str="";

valtozot, majd hozzarakjuk a foreach testeben az echo-s sorok helyett a HTML-t:

$hiba_str.='<li;>'.$hiba.'</li>';

es ezt kene valahogy belevarazsolni a Joomla template-jebe. Hogy ezt epp hogy kell, az a joomla-tol fugg; template nyelvbol annyi van viszont mint a csuda, es ezeket a muveleteket MINDIG ismerik. (Tobbet is neha, de ez nem mindenfelekeppen jo)

>>> Nem gyartunk javascript utasitasokat php-bol
>>akkor hogyan adod at, egy php valtozo erteket a javascriptnek?
> Nyugtass meg, hogy nem adnak neked penzt webfejlesztesert.
Nem tudom miert kell piszkoskodnod, 10 darab szobol megallapitotad mennyire ertek hozza. Gratulalok.

> Nyilvan vagy HTML-ben, vagy JSON-ban, de semmikepp nem utasitaskent)
mondhatnam en is hogy a HTML egy jelolonyelv, nem tud sokkal tobbet mint egy dokumentum, megnezheted de benne nem lehet kuldozgetni semmit. De nem mondom mert nem tudom mit akartal mondani. Rengeteg modszer van egy problema megoldasara, egyike lehet akkar ez is.

Vannak helyzetek amikor igenis tanacsos javascriptet php-bol generalni, ha html-t lehet akkor js-t is. Azert mert te nem talalkoztal meg ilyen helyzettel nem az ordogtol valo, es irtani kellene. Nem mind1 hogy egy ezer vagy tobb tizezer soros sitot kell csinalni esetleg egy olyan munkaban veszel reszt ahol dologznak 200 an rajtad kivul.

Na jo, talan sikerult megnyugodnom, elnezest. Volt nagyon sok tapasztalatom ilyen koddal, es nagyon sok tapasztalatom olyan programozokkal, akik keptelenek latni a minta alapveto hibait. A tapasztalat az, hogy ezeknel az embereknel nem csak ez hianyzott, es igy mara az egyik vetokerdesse valt tenyleg.

De mi a baj vele?

A strukturalt programozasnak van ket torvenye. Az egyik, hogy nem irunk onmodosito programot. Ezt vilagosan fel szokta fogni mindenki kozepiskolaban vagy elsoben, hogy nehany programozo latott ilyet regen, es ki kellett debuggolniuk, ez pedig akkora sokkot okozott, hogy 30 eve tabu.

Konnyen bebizonyithato, hogy az ilyen szoftver voltakepp onmodosito.

A masik alaptorveny, hogy adatstrukturak+algoritmusok = program. Ennek a Wirth-tol szarmazo szabalynak trivialitasan tul van egy kovetkezmenye: nemcsak, hogy szetvalaszthato mindig az adat es az algoritmus, de szet is valasztando!

Namost nyilvan ettol meg leteznek kodgeneratorok es forditok, es a Neumann-architektura alapveto lehetosege, hogy a program maga is kezelheto adatkent. Ettol meg ez egy nagyon szuk korben ertelmezendo valami.

A fenti "peldaban" a php algoritmus egy masik szamitogep szamara general egyszerre adatsrukturat (raadasul ket terben, js es html) es algoritmust. Ugyanis kliens-szerver architekturakent a webes rendszerek mindig ket szamitogep, ket szoftver egyuttmukodesekent jonnek letre.

Egy ilyen stilusu, html-be agyazott kodgeneralasnal a kliensben van egy olyan algoritmus, ami egyaltalan nem all ossze egybefuggo kodsorra, innentol kezdve pedig debuggolasrol tulajdonkeppen nem beszelhetunk.

Nyilvan lehet jonni, hogy ott a jsonp - az egyetlen korlatos kitetel egy ismert technologiai problema elharitasara, de a HTML5 tervezet mar igyekszik korrektebb megoldast adni ra; a jsonp rendszerek bizonyos modellezesi szempontbol nem generalnak algoritmust, mivel nem hataroznak meg viselkedest.

A google web toolkit eseten a kliensoldali modul egyszerre generalodik tudtommal, bar senkinek nem javasolnam a gwt hasznalatat, mert igy is verzik, ott tulajdonkeppen egy atomi on-demand forditasrol beszelunk, igy megjelenik az egyseges kliensoldali algoritmus.

Amiert haragszom az ilyen kodokert, hogy a fent emlitett tabu resze a klasszikus informatikai kepzesnek. Akiben nincs meg ez a tabu, abbol rendszerint hianyzik az, hogy kiszamithato modon programozzon. Ez bizonyos kornyezetekben, tobbszaz programozo koordinalasanal viszont elvaras.

A masik oldalrol az alapelvek liberalis megkerdojelezese szemely szerint nekem ketsegeket szokott felvetni az illeto tudashoz valo hozzaallasaval kapcsolatban: nem a kanon megkerdojelezese, hanem az annak ismeretenek hianya es emiatt kotozkodes rendszerint olyan szemelyiseget rejt, akivel keptelensegnek tartom, hogy kepes lennek egyutt dolgozni, vagy munkajat befogadni barmi modon, mert soha nem talalkoztam meg olyan emberrel, aki ezzel a hozzaallassal rendelkezett, es szamomra elviselheto minoseget adott volna ki a kezebol. Elnezest.

( redman | 2011. 07. 15., p – 15:55 )

Nem értem miért bántjátok, és nem a kérdésre próbáltok válaszolni. Illetve a valódi problémát megoldani.
Mindenki csak okoskodik, hogy az aktuális programozási dolog nem jó, mert nem oda teszi a vesszőt, kisbetűt használ, nem tesz szóközt, nem tagol stb.
Jelen esetben ez most nem érdekes szvsz.
Nem ez volt a kérdés.
Reménykedjünk, hogy ez most csak egy próbálkozás és ha az alapok megvannak, akkor kijavít minden programozási és egyéb hibát.

http://www.redman.hu

Szerintem meg épp most kell neki más megoldási módokat is prezentálni. Ahogy Aadaam tette, az meglehetősen előremutató és értékes segítség. Felvázolt egy sokkalta jobb/szebb/hatékonyabb megoldást, amihez hozzá is tette a végén, hogy azért ezen túlmenően is vannak még megoldások a problémájára, ha akar, akkor merre kapirgáljon.

Ha meg a felvázolt lehetséges megoldás kínaiul hangzik számára, de komolyan akar foglalkozni a kérdéssel, akkor ezen generálgatásos próbálkozások helyett inkább arra koncentráljon, amit javasolt Aadaam, azzal sokkal messzebbre jut.

Teljesen igazad van, és nekem is tetszik a fenti megoldás, előremutatás, de én azokat bíráltam akik idejönnek aztán beleböfögik a fórumba, hogy ez így nem jó, és ne programozzál soha többet, mert úgysem fog sikerülni és persze nem mondják meg, hogyan kéne. Akinek nem inge ne vegye magára. És ezt általánosságban mondom, nem csak erre a témára nézve.
Na de nem akarom szétoffolnni a topicot, csak kicsit felhúztam magam.

http://www.redman.hu

Nem az a baj, hogy nekem szólt, hanem azt, hogy azt mondja, hogy nem jó, de azt nem mondja meg, hogy mi a megoldás.
Úgy gondolom, hogy ez a fórum azért jött létre, hogy segítsen másoknak építeni a tudást.
Az sajnos nem építő jellegű, ha azt mondom, hogy ez nem jó, aztán kész.
Tudom, hogy nekem is van még mit fejlődni. Mindig is kell majd és senki nem mondhatja el magáról, hogy én mindent tudok és mindent a legjobban.
Szóval ha valaki hozzászól, akkor én elvárnám, hogy segítő szándékkal tegye, ne pedig az legyen , hogy leosztja a másikat.

Üdv: redman

http://www.redman.hu