Új hozzászólás Aktív témák

  • Sk8erPeter

    nagyúr

    válasz adam_ #17129 üzenetére

    Na pont ez egy tökéletes példa arra, hogy miért is egy rakás szar még mindig a w3schools, ahhoz képest, hogy sokan azt hiszik, ez a webfejlesztők referenciáinak alfája és omegája, miközben tele van okádmány példakódokkal, rossz praktikákkal.

    Egy külön szekciót szentel annak, hogy elmagyarázza, miért csinálja ezt:
    <form method="post" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>">
    ahelyett, befejezné a szerencsétlenkedését, és ennyit írna:
    <form method="post" action="">
    üresen hagyva az action-attribútum értékét, ha már önmagára akarja irányítani a formot... Kész, probléma megoldva... :U De még véletlenül sem hívja fel a figyelmet, hogy amúgy nem igazán üdvös megoldás nem szétválasztani a megjelenítéshez tartozó kódot a kapott adatok feldolgozásához tartozó kódtól...
    Az input fieldeknél meg még véletlenül se használna labelt az accessibility és könnyebb kezelhetőség jegyében (pl. labelre kattintva ugorjon bele a mezőbe, ezt a böngészők támogatják, ha a label tartalmazza az általa felcímkézett elemet, vagy össze van kapcsolva egy for attribútum segítségével), nem használ placeholdert, mert ugyan miért is lenne HTML5, töketlenkedik azzal, hogy egyesével adogatja át a $_POST tömbben szereplő változókat az indexszel azonos nevű változóknak validálás után, ahelyett, hogy jóval általánosabb és szebb módon oldaná meg, és így tovább... nem értem, miért nem tudják az embereket spagettikód írása helyett végre valami jóra is tanítani.
    Szóval látom, a w3fools.com-nak sajnos még mindig van relevanciája.

    "Itt találtam egy pár funkciót ami a hibakijelzésekre vonatkozik, igazából vakvilágban tapogatódzom, segítenél, hogy pontosan mely fájlokat kell a php.ini-ben bekapcsolni ahhoz, hogy kijelezze a php-s hibákat is?"
    Jó helyen tapogatózol, de itt nem "fájlokat" kapcsolsz be (ezt nem is tudtam értelmezni), hanem opciókat állítgatsz be (a php.ini egy konfigurációs fájl).

    Hibajelzésekre:

    PHP 5.4.0 fölötti változatoknál:
    error_reporting=E_ALL
    display_errors=On

    PHP 5.4.0-nál régebbi esetén:
    error_reporting=E_ALL|E_STRICT
    display_errors=On

    "Majd ezt követően a debuggolás történhet pl. etc. Firebuggal, konzolon keresztül? (Perpill ugye ott nem ír ki semmit sem)."
    Húha, itt alapvető fogalmi tévedések vannak. A kliensoldalnak semmi köze a szerveroldalhoz, attól még, mert kommunikálnak, azok fejlesztése, debuggolása, lehetőségei is totálisan eltérnek. Bármilyen böngészőbeli webfejlesztő panelen csak akkor látnád ezeket a hibákat, ha JavaScripttel kiíratnád őket explicite valahogy a konzolra (ez már a gányolás kategória).
    Ezért kell megtanulni rendesen debuggolni, de ez egyelőre sztem még nehézkes lenne neked, gondolom most kezded tanulni a PHP-t.

    "Tehát pl. hozzak létre egy contatform.php és külön csak abba legyen a kontaktformhoz tartozó php kód?"
    Egy olyan fájlról beszélek, aminek elküldöd az űrlap adatait (ezt a fájlnevet az action-attribútumban adod meg), és aminek a megjelenítéshez semmi köze, nincs benne az űrlap kiírásáért felelős kód, stb. Megkapod az adatokat, validálod őket, gondolva az esetleges csúnyabácsikra, kezdesz az adatokkal valamit (jelen esetben küldesz egy mailt), aztán visszairányítod az egészet abba a fájlba (header() segítségével), amiből kiindultál (vagy valahova átirányítod a júzert, ahol jelzed neki, hogy milyen ügyes volt, és sikeresen elküldte a cuccát). Itt a feldolgozó fájlban a különböző, másik oldalon kiírt adatokat el lehet tárolni $_SESSION-változókban, de ha ez egyelőre magas, akkor maradj az eredeti megoldásodnál, amikor önmagára irányítod az űrlap adatait (üres action-attribútummal).
    Vagy ha valakinek van türelme elmagyarázni, akkor az remek. :D Most látom, így is qrva sokat írtam. :D

    [ Szerkesztve ]

    Sk8erPeter

Új hozzászólás Aktív témák