Jump to content
GSForum - Segélyvonal

PHP kérdésem van


Recommended Posts

Posted

$_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ó.

Posted

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.

Posted

Milyen nevet adtál az input-nak?

Posted

sonkaskicsi nevet adtam az inputnak <input type="text" name="sonkaskicsi" size="1"> és ezt is átírtam rá $_POST["sonkaskicsi"]

Posted

Nos, azt hiszem, nyugodtan megvárhatjuk mások véleményét is. :)

Posted

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;amp;#097;v&amp;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;amp;#097;v&amp;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!". :hááát: É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? :hááát:

 

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.

 

 

Posted

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.

Posted

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. :igen:

Posted

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.

  • 10 months later...
Posted

$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

Posted

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.

Posted

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ó. :D Mellette tud még pár extrát is, így egy függvényben összefoglaltam az összes sql dolgokat.

  • 1 month later...
Posted

Én meg inkább tárolt eljárásokat használok.

  • 3 months later...
Posted

Ó, 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.

Posted

A ... meg ** még hasznos is lehet, a többi engem nem érint. :D Ezt a debuggert nem ismerem, majd meg kell nézni. De ** miért nem a ^-t használják?

Posted

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.

Posted

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

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.

Posted

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. :D 5.3 óta vannak névtereink is.

 

Miben objektumorientáltabb a .NET? :hááát:

[OP]Destroy-man
Posted

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).

Posted
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.

Posted

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.

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...