kléni Posted May 26, 2013 Posted May 26, 2013 $_POST["1. Sonkás pizza (20cm)"] Ilyen biztos, hogy nincs. A HTML-ben az űrlapmezők nevének angolnak kell lennie, szóköz, speciális karakterek és minden más nélkül. Mintha egy PHP-s változó neve lenne. if (!empty($_POST["1. Sonkás pizza (20cm)"])) { $uzenet .= "SK: " . strips($_POST["1. Sonkás pizza (20cm)"])."\n"; else $uzenet .= "1.K: ".strips($_POST["sonkas"])."\n"; Itt láthatod, hogy bármit írhatott be a mezőbe a felhasználó, mindkét esetben hozzáteszel egy szöveget a $uzenet-hez. Mivel az if-ben ! empty()-t használtál, ha a mező nincs kitöltve, az else ág fog lefutni, így ha nem akarsz hozzátenni az üzenethez ebben az esetben, töröld ki az else-t. Feltételezem az input neve miatt nem működött most megfelelően. A $_POST["1. Sonkás pizza (20cm)"], mivel ilyen nincs, semmit adott vissza, így minden esetben az else ág futott le, ami azt eredményezte, hogy mindig hozzátett valamit a levélhez. Írd át az <input> name attribútumát, és menni fog. Ha máskor ilyen hibával találkozol, írd ki a változókat a böngészőbe az if elé, és meglátod, hogy melyik a nem jó.
totti111 Posted May 27, 2013 Posted May 27, 2013 Köszönöm a választ, megpróbáltam úgy is, kitöröltem az else tagot és átírtam $_POST["1. Sonkás pizza (20cm)"] ezt is mindenféle ékezetek egyebek nélkülire, de akkor az a gond, hogyha kiveszem az else-t akkor ha írok a mezőbe akkor se jeleníti meg azt a sort az e-mailbe.
totti111 Posted May 27, 2013 Posted May 27, 2013 sonkaskicsi nevet adtam az inputnak <input type="text" name="sonkaskicsi" size="1"> és ezt is átírtam rá $_POST["sonkaskicsi"]
kléni Posted May 27, 2013 Posted May 27, 2013 Nos, azt hiszem, nyugodtan megvárhatjuk mások véleményét is.
payskin Posted May 28, 2013 Posted May 28, 2013 Aludtam rá, szeretnék konstruktívan hozzáállni, de nem értem a programot. Például itt van ez a szörnyűség: // nem kötelező kitölteni if (!empty($_POST["1. Sonkás pizza (20cm)"])) { // ez egy textfield echo "<h4>Nincs Sonkás pizza (20cm) megadva!</h4>"; echo "<a href='j&amp;amp;amp;#097;v&amp;amp;amp;#097;script:history.back(1);'>Vissza</a>"; $hibas_kitoltes = true; $uzenet .= "SK: " . strips($_POST["1. Sonkás pizza (20cm)"])."\n"; } else $uzenet .= "1.K: ".strips($_POST["sonkas"])."\n"; Kezdjük ott, hogy ezt normálisan úgy írjuk, hogy // nem kötelező megadni if (!empty($_POST["1. Sonkás pizza (20cm)"])) { // ez egy textfield echo "<h4>Nincs Sonkás pizza (20cm) megadva!</h4>"; echo "<a href='j&amp;amp;amp;#097;v&amp;amp;amp;#097;script:history.back(1);'>Vissza</a>"; $hibas_kitoltes = true; $uzenet .= "SK: " . strips($_POST["1. Sonkás pizza (20cm)"]) . "\n"; } else { $uzenet .= "1.K: " . strips($_POST["sonkas"]) . "\n"; } Problémák: 1. A !empty (jelentése: NEM ÜRES) akkor lesz igaz, ha az ember kitöltötte a mezőt. Ekkor közöljük vele, hogy "Nincs Sonkás pizza (20cm) megadva!". Én itt némi ellentmondást vélek felfedezni. 2. Miért foglalkozunk egyáltalán hibaüzenet gyártásával, ha azzal kezdődik a blokk, hogy // nem kötelező megadni? 3. Minek kéne jönnie a POST-ban? Hogy hány pizzát rendelt? Kellene látni a HTML-t hozzá. 4. Az else ágban a $_POST["sonkas"] milyen relációban van a $_POST["1. Sonkás pizza (20cm)"] változattal? Tartok tőle, hogy ott is valami elírás lesz. 5. A POST szomorúságát már Klénivel sikerült tisztázni, annyit tennék hozzá, hogy a számítástechnika csodálatos világában általában SEMMIT nem azonosítunk a nevével, hanem lehetőleg egy egyszerű, numerikus (szám jellegű) azonosítóval. 1 = Sonkás pizza (20 cm), 2 = Gombás pizza (20 cm), 3 = Szalámis, és így tovább. Felállítunk egy ilyen remek szám - pizza neve táblázatot, beírjuk a program legelejére egy (adat)tömbbe, és az űrlapokban valamint az adatfeldolgozóban már csak a sorszámát, azonosítóját használjuk. Így az a hihetetlen szerencsés eset áll elő, hogy ha mondjuk 48 pizzánk van, akkor nem kell 48-szor beírni a fenti rettenetességet, hanem elég EGYSZER, és az az egy kód képes lesz mind a 48 pizzát ellenőrizni. Mi volt a kérdés? Ja, hogy ne küldjön, ha üres a mező. Ha úgy nézzük, hogy a // nem kötelező megadni az első sor, akkor dobd ki a 3., 4., 5., 6. sort és a teljes else ágat, és máris csak akkor küld, ha kitöltötték a mezőt, és nem küld hibaüzenetet.
totti111 Posted May 30, 2013 Posted May 30, 2013 Köszönöm a segítséget, így már sikerrel jártam! Ahogy írtam az elején ez egy generáló program volt, mert én még csak most tanulmányozom a php nyelvet, köszi az észrevételeket is, megjegyzem, hogy inkább sorszámazonosítót használjak majd ezentúl ha egyszer odajutok, hogy magamtól összeálltok egy ilyet.
payskin Posted May 30, 2013 Posted May 30, 2013 Annyit tennék hozzá, hogy sokkal szívesebben segítenék neked a tanulás, gyakorlás során felmerült kérdések, problémák megválaszolásában, mint kódgenerátorral gyártott szemétdomb mazsolázásában.
totti111 Posted May 30, 2013 Posted May 30, 2013 Remélem én is, hogy nem kell mostmár többet ilyen generátorokat alkamaznom, de hirtelen megoldásnak jónak, meg könnyűnek tűnt.
kléni Posted April 5, 2014 Posted April 5, 2014 $s = $mysql->prepare("SELECT blog.*, COUNT(comments.id) AS comments FROM blog LEFT JOIN comments ON blog.id = comments.bid WHERE 1=1 AND blog.text LIKE '%?%' GROUP BY blog.id ORDER BY blog.date DESC LIMIT ?, 10"); $a = "a"; $b = 0; $s->bindParam(1, $a, PDO::PARAM_STR); $s->bindParam(2, $b, PDO::PARAM_INT); $s->execute(); Van tippetek, erre miért ad ilyet: PDOStatement::execute(): SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens
Dani991 Posted April 5, 2014 Posted April 5, 2014 Próbáld meg így: $s = $mysql->prepare("SELECT blog.*, COUNT(comments.id) AS comments FROM blog LEFT JOIN comments ON blog.id = comments.bid WHERE 1=1 AND blog.text LIKE ? GROUP BY blog.id ORDER BY blog.date DESC LIMIT ?, 10"); $a = "%a%"; $b = 0; $s->bindParam(1, $a, PDO::PARAM_STR); $s->bindParam(2, $b, PDO::PARAM_INT); $s->execute(); Nem próbáltam ki, csak egy tipp. Úgy írtam át, hogy az első kérdőjel ne legyen aposztrófok között az SQL-statementben, ennek megfelelően a százalék jeleket átraktam az $a változóba.
payskin Posted April 6, 2014 Posted April 6, 2014 De miért így használod? A PDO-ban pont az a jó, hogy nem kell kérdőjelekkel bohóckodni, mint a mysqli-ben, hanem nevesített paramétereket használhatsz. Doksi: http://hu1.php.net/manual/en/pdostatement.bindparam.php
kléni Posted April 6, 2014 Posted April 6, 2014 Mert teljesen felesleges nevet adni neki, és a lustaság nagy úr. Írtam egy sima függvényt, aminek az első paramétere a query string, a többi pedig a ?-et helyettesítő változó. Mellette tud még pár extrát is, így egy függvényben összefoglaltam az összes sql dolgokat.
Dani991 Posted August 28, 2014 Posted August 28, 2014 PHP 5.6.0 Release announcement New features Tessék tanulmányozni!
payskin Posted August 28, 2014 Posted August 28, 2014 Ó, köszi, én is szándékoztam kirakni! Már tanulmányoztam is, van egy-két dolog, amit nagyon nem értek, és erősen ráncoltam a homlokom.
kléni Posted August 28, 2014 Posted August 28, 2014 A ... meg ** még hasznos is lehet, a többi engem nem érint. Ezt a debuggert nem ismerem, majd meg kell nézni. De ** miért nem a ^-t használják?
Dani991 Posted August 28, 2014 Posted August 28, 2014 A ^ operátor már foglalt: ez a bitenkénti kizáró vagy operátor, a ** meg már bevett szokás más szkriptnyelv(ek)ben.
payskin Posted August 28, 2014 Posted August 28, 2014 Hát már a három ponton is csodálkoztam, mert totál olvashatatlanná teszi szerintem a kódot, de oké. Viszont a use const meg a use function az teljes döbbenet. Ez hogy nem köpi szembe az objektumorientált alapelveket vajon? Nem azért pakoltuk a függvényeket globális függvénykönyvtárakból enkapszulált objektumokba, hogy minden és mindenki megfelelően szeparálva legyen? Erre most így összerángatunk majd ezt-azt különböző objektumokból? Ezt így hogy? Jó, az 5.4-ben meg kaptunk traitet, aztán arról is olvastam, hogy nem igazán kéne használni, antipattern. Csupa jóság.
[OP]Destroy-man Posted August 28, 2014 Posted August 28, 2014 Az a baj a PHP-vel, hogy C alapú. Az meg nem objektum orientált nyelv. Ugyan a PHP-ben bőven kiegészítették a sima C nyelvet, és próbálkoztak objektum orientált irányba elmenni vele, de azért ez még nem nevezhető annak. Inkább csak objektum orientált szerű nyelvnek. Ha objektum orientált webprogramozás érdekel, akkor ott van az ASP.NET és az ASP.NET MVC. Bár tény, hogy az üzemeltetése sok esetben drágább, mint a PHP-é, de nem olyan sokkal. Inkább az a furcsa, hogy a Linux serverekre nem telepítik fel a mono-t, pedig a jelenlegi változata már szinte mindent* elkezel a leírása alapján (bár tesztelni nem teszteltem). *: 1-2 modul hiányzik a .NET 4.5-ös verzióból, a 4.0 és az alattiak 100%-osan támogatottak.
payskin Posted August 29, 2014 Posted August 29, 2014 Amit írsz az a 4-es verzióra volt utoljára igaz, de a PHP 5.0 óta teljesen objektumorientált, és ennek éppen idén ünnepeltük 10 éves évfordulóját. 5.3 óta vannak névtereink is. Miben objektumorientáltabb a .NET?
[OP]Destroy-man Posted August 29, 2014 Posted August 29, 2014 Nagyon leegyszerűsítve a .NET-es weblapok ugyan úgy épülnek fel, mint a benne írt szoftverek, csak a GUI nem XAML (vagy extrém esetben WinForms), hanem HTML. Persze a küldés itt is FORM-ról megy, de elkapni már nem egyesével fogod az értékeket, hanem egy előre megírt objektumot vár a fogadó kód. A PHP weboldalán még mindig az áll, hogy egy script nyelvről van szó, azok meg nem igazán objektum orientáltak. Hajaz rá, az tény, és meg is lehet oldani 1-2 dolgot, hogy úgy működjön, mintha objektumorientált lenne, de ettől még nem lesz az. Hogy mitől objektumorientált a .NET? Az MS szerint ettől. De ezen kívül még sok más dolog is van, amitől objektumorientált. Például az adatbázist is objektumként éred el, és aszerint is dolgozol vele. Az adatbázisban lévő táblák List<> objektumok, a benne lévő adatok pedig a soroknak megfelelő változók. Ennek köszönhetően még SQL lekérdezéseket sem kell írnod. Persze ha régi módi az ember, akkor van rá lehetőséged, de minek írni több 10 soros programkódot, amikor az 3-4 sorban is megoldható, ráadásul az utóbbi akár még több szálasítható is, ennek köszönhetően sokkal gyorsabban le is fut (persze ha a server beállítások engedik).
Dani991 Posted August 29, 2014 Posted August 29, 2014 Hát már a három ponton is csodálkoztam, mert totál olvashatatlanná teszi szerintem a kódot, de oké. A ... operátort gondolom, hogy a C++ variadikus template paramétere ihlette, tehát nem teljesen szokatlan jelenség. Nem ismerem az ASP.NET-et, de a PHP-t én sem nevezném objektumorientáltnak, mivel nincs meg benne minden objektumorientált feature. Nincs például többszörös öröklődés, de kaptunk helyette traiteket, ahelyett, hogy azt megcsinálták volna. Hogy egy ismerősömet idézzem, ez csak egy objektumorientáltnak csúfolt nyelv.
kléni Posted August 29, 2014 Posted August 29, 2014 Azért azt tegyük hozzá, PHP-ban való programozás közben nem is szükséges annyira az objektumokkal vacakolni, mint más, direkt erre kifejlesztett nyelvekben. Az objektumok itt inkább csak az oldalakat feldolgozó funkciók rendszerezéséhez, hogy külső könyvtárak betöltéséhez kellenek. A weboldalak elkészítésénél nem kell sokat variálni, mint egy szoftver elkészítésénél. Bár, ez még nem mentség a jelenlegi helyzetre.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now