PHP kérdésem van

[payskin]

Destroy-man, tudod mi a különbség egy programozási nyelv és egy arra épülő keretrendszer között? Mert ha nem, akkor tudok egy tök jó új programozási nyelvet, isten-császár, objektumorientált, úgy hívják Laravel. És képzeld, objektummal lehet benne SQL-t vagy bármilyen más adatbázist kezelni úgy, hogy egyetlen sor SQL-t nem kell hozzá írnod, és ezt meg úgy hívják Doctrine.

 

A PHP tényleg gagyi (), de ez a Laravel, na ez valami állat.

 

Egyébként abból talán 2 dolgot nem tud a PHP.

 

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

 

Miért, miben van meg minden objektumorientált feature? (Gondolom, a SmallTalkban.) Egyáltalán mit jelent az, hogy "minden"? Valahol definiálva van? Ha holnap kitalálnak egy objektuorientált feature-t, akkor egyetlen programnyelv sem lesz a világon, ami objektum-orientált? Ugye nem?

 

Nézd már, mit olvasok a Wikipedián, hogy aszondja:

 

Languages that support multiple inheritance include: C++, Common Lisp (via Common Lisp Object System (CLOS)), EuLisp (via The EuLisp Object System TELOS), Curl, Dylan, Eiffel, Logtalk, Object REXX, Scala (via use of mixin classes), OCaml, Perl, Perl 6, Python, and Tcl (built-in from 8.6 or via Incremental Tcl (Incr Tcl) in earlier versions).[5]

 

Some object-oriented languages, such as C#, Java, and Ruby implement single inheritance, although protocols, or interfaces, provide some of the functionality of true multiple inheritance.

 

Ezek szerint a C# meg a Java sem objektumorientált? Hű de nagy baj.

 

Szerintem az lenne a legokosabb, ha nem ragadtatnánk el magunkat ilyesmi kijelentésekre, valamint nem címkéznénk már fel a különböző programozási nyelveket mindenféle pejoratív djelzővel azért, mert az nem a mi szájízünk szerint való.

 

És akkor még elő sem vettem az aduászt, hogy a világban vajon hány weboldal készül PHP-ban és mennyi .NET-ben. Csúnya csúnya grafikonokat találtam.

[Fujitsu]

Ha az MS fejlesztené, mindjárt kiváló OOP nyelv volna.

[Dani991]

Szerintem az lenne a legokosabb, ha nem ragadtatnánk el magunkat ilyesmi kijelentésekre, valamint nem címkéznénk már fel a különböző programozási nyelveket mindenféle pejoratív jelzővel azért, mert az nem a mi szájízünk szerint való.

 

Mondjuk ebben van valami. Lehet, hogy ezt már az ELTE-n tanultam. Igaz, ott C++ és Java között ment a sárdobálás, de ott aztán rendesen. Mindezzel természetesen nem lehúzni akarom az intézményt, mert amúgy kiváló képzések vannak mindkét programnyelven, minden tiszteletem az oktatóké!

[Pjotr]

@Balázs:

Trait-ek jó dolgok, csak ésszel kell használni őket, pl. http://logout.hu/bej..._trait-tel.html

Annyi biztos, hogy pakolnak bele az új verziókba használhatatlan vagy teljesen értelmetlen dolgokat, de egyszerűen nem kell ezeket használni, a most megjelent újak közül szerintem egyiket sem fogom az életben.

 

@[OP]Destroy-man:

Igen, te nagyon kevered a dolgokat.

[payskin]

Hehe, bíztam benne, hogy jössz, és majd helyre teszel minket OOP-ügyileg.

[Pjotr]

Láttam egy kék elefántot az égen este, tudtam, hogy baj van.

[arpsoft]

Jesszusom! Ki volt az az elvetemült, aki objektum alapokon kezel egy SQL adatbázist? Az SQL-nél biztosan nem lesz gyorsabb, márpedig egy adatbázisnál ez a legfőbb szempont szerintem.

[Pjotr]

Itt leginkább query generálásról van szó, nem olyanról, mint pl. a Microsoft DataSet-je.

[mtom75]

Üdvözletem!

 

Nem tudom jó helyre írok e.

Van egy készülő webshopom melybe már több száz terméket felraktam, de viszont a termék leírásnál a tartalmat szeretném kicsit meg formázni.

html nézetbe így néz ki:

Videó

Videó tömörítés: H.264, Motion JPEG és MPEG-4

Felbontás: 1280x800

Képátviteli sebesség: 25 kép/mp.

Videó folyam: Egyidejû H.264, MPEG-4 és Motion JPEG

Háttérfény kompenzáció

 

 

Bőngészőbe viszont egysorba jelenik meg.

 

Én azt szeretném elérni, hogy az alábbi formában jelenjen meg.

-Videó

-Videó tömörítés: H.264, Motion JPEG és MPEG-4

-Felbontás: 1280x800

-Képátviteli sebesség: 25 kép/mp.

-Videó folyam: Egyidejû H.264, MPEG-4 és Motion JPEG

-Háttérfény kompenzáció

 

<ul> tagek közé szeretném tenni.

Hogyan tudom ezt a legegyszerűbben megoldani?

 

Köszi Tamás

Edited November 27, 2014 by mtom75

[kléni]

Ha jól sejtem, nem te írtad a weboldalt, hanem valami webáruházat felraktál. Jó lenne tudni, pontosan milyen CMS-t telepítettél. Azon belül meg kell keresned a témakezelő részt, és ott módosítani.

[payskin]

mtom, szerintem az a legegyszerűbb, ha felraksz róla egy képet ide, hogy lássuk, miről van szó.

[Pjotr]

Téma iránt érdeklődőktől kérdezném, egy ilyesmi (.PHP SQL-ezés) hogy tetszik?

[kléni]

Nem tudom elképzelni, mire kellhet bárkinek is ilyen?

[Pjotr]

Nyilván nem 5 táblás adatbázisokhoz kell ilyen, de egy kicsivel komplexebb alkalmazáshoz már elégtelen az, ha meztelenül használod a PHP SQL drivereit (illetve nem is működnek). Amint fejlesztesz egy "platformot", máris kiütközik, hogy a különböző adatbázisok támogatása nem megoldott alapból, a PDO ilyenre történt próbálkozás, de a rossz végén fogták meg a dolgot.

 

Szoftverfejlesztésileg egy ilyennel már lehet unit/integrációs teszteket futtatni, meztelenül használt driverekkel meg nem.

[Dani991]

Mi is a probléma a PDO-val? Mármint nem "meztelen" PDO használatra gondolok, hanem egységbe zárva, az sqlsrv_* helyett. Az SQL server streamre itt egy példa, az utolsó kódrészlet PDO-t használ. És azt el tudnád magyarázni, hogy pontosan mi az a @@IDENTITY? Oké, már megtaláltam.

[Pjotr]

Lehet, hogy mysql esetén nem megy rendesen a BLOB-olás, rosszul emlékezhettem: https://bugs.php.net/bug.php?id=40913

Viszont olvasni mintha nem tudna SQL Server-ből sem, MSDN-en sem látok példát rá.

 

A Microsoft SQL driver-e egyébként eddig a legkulturáltabb.

Edited January 4, 2015 by Pjotr

[Dani991]

Én nem szoktam olyan túl nagy rendszereket írni, így nekem a PDO funkcionalitása elegendő szokott lenni, de ha ennél több kell, akkor szerintem jó megoldás. És nemcsak, hogy jó, hanem az egyetlen megoldás. Bár én így is megpróbálnék PDO-t használni azokhoz az adatbázisokhoz, amelyeknél jól működik.

[kléni]

Egy fórumot még meg lehet oldani a PDO-n keresztül, világhírű oldalt pedig pont azért nem PHP és SQL párosban kellene készíteni, mert nem a legjobb teljesítményről híresek. Más programozási nyelvekkel nem csak az adatbázis részt tehetnénk gyorsabbá, de minden mást is. Akkor pedig miért kellene PHP-ban ilyen szépségekkel vacakolni?

[Pjotr]

Végül is bármilyen oldalt jobb megcsinálni mondjuk ASP.NET-tel. Teljesítményt ne keverjük bele, mert amikor valami lassú, akkor általában a fejlesztő tolt el valamit.

A lényeg az, ha valamit csinálsz, csináld meg rendesen. Fórumot sem biztos, hogy meg lehet oldani, hiszen kissé nehézkes lesz tesztelni PDO-val, tesztnek messze nem elég az, hogy kipróbálod, jé, működik, készen is vagyunk.

[kléni]

Hát mi kell még neked? Én írtam magamnak pár éve egy komplett sql-es függvényt, ami PDO-ban működik, minden általános műveletre jó, és ha hiba van, a kapott paramétereket, meg a query-t kiírja a hibaüzenettel. Ennél többre még sosem volt szükségem, mert az esetek többségében a paraméterek egyike hibás, vagy elírtam a query-t. Más debug infó mi kell még neked? És a linkelt oldalon lévő csoda kód mit ad még pluszban? Igazából azt sem értem, mit csinál az a csoda kód. Én megvagyok a saját függvényemmel, ami rövid, egyszerű, mindenre jó, más nem kell.

[Pjotr]

Mutasd az a függvényt.

[kléni]

Hát, éppenséggel nem egy db. függvény. Pár hónapja már nem programoztam, elfelejtettem. De ez nem változtat semmin.

 

http://www.codeshare.io/OveXp

 

BLOB egyébként mire kell neked? Én még sose használtam. Ilyen dolgokat minek adatbázisban tárolni? Képeket fájlrendszeren keresztül is lehet menteni.

Ez a @@IDENTITY meg röviden a last insert id megfelelője lenne? Hát az pech, de én MySql-t használok, és egyelőre minden megvan, ami kell bele. Persze ha te minden áron MSSql párti vagy, akkor kell keresni valami alternatívát, de nálam elég volt csak a kényelmi függvényeket megírni, nem a rendszer hibája miatt dolgozni.

[Pjotr]

Van néhány előnye annak, ha fájlokat adatbázisba raksz be, személyes kedvencem, hogy megfelelő fájlokat lehet FULLTEXT index-elni, így kereshetővé válik. Képeket nem sok értelme van betolni ebből a szempontból, de elvileg lehetne írni OCR-ező IFilter-t MSSQL-hez.

 

---

 

Megnéztem a kódodat is, azt kell mondjam, ez használhatatlan, ugyanis csak rossz példák vannak benne.

 

Első függvény: function sql() { /* ... */ }

 

Mit mond ez annak, aki használni szeretné, akár neked? Szerintem semmit, nincs bemenete, mégis mit adna vissza?

Belsejében global $mysql, de ez honnan jön? Később kiderül, nem is az ez sem, aminek látszik!

 

Utána folytatódik valami igazi fekete mágiával, ami megpróbálja összeszedni a paramétereket, és kitalálni, hogy mégis mit is kellene csinálni. Programkódnak nem szabad találgatnia, mert nem okos programod lesz, hanem egy rakás öntött vasad, ami semmire sem jó.

 

Derítsük ki, mi az a $mysql, meg is van, sql_connect($host, $user, $pass, $db) hozza létre, vajon az, aki ismeretlenül ránéz az sql() függvényre, tudja, hogy ezt meg kellene hívni? Nem hiszem.

 

Connect-en belül a $mysql kiderül, hogy igazából $pdo lenne, de teljesen mysql specifikusan indul el. Hibakezelés a lehető legrosszabb módon van kivitelezve, elkaszálod az Exception-t, pedig ilyenkor a helyes az lenne, hogy ezt tovább viszed akár egy saját Exception-ön keresztül (die() nem lehet production kódban, ezek az idők elmúltak egy 10 éve).

 

Hibakezelésről kicsit emlékezzünk meg, a PDO alapből silent módban megy, ami azt jelenti, hogy nem dob kivételt, és nem is triggerel PHP error-t, neked kell mindig ellenőrizned, hogy történt-e valami. Kinek van erre ideje? PDO létrehozásakor be kell állítani, hogy mindig dobjon exception-t, és kész.

 

Az elsőnek említett sql()-ben is ellenőrizve van, hogy a query-nek sikerült-e végrehajtódnia, ha be van állítva, hogy dobjon kivételt a PDO, erre semmi szükség.

 

A többi függvény hasonló, mint az sql(), próbálnak találgatni, mit is kellene csinálni (pl. paraméterekből nem csak kétféle játszana), rowCount()-ot nem erőltetném, normális dokumentáció híján nem is vagyok benne biztos, mi alapján működik, ugyanis alapból a PDO MySQL-lel unbuffered query-t használ, így vagy kétszer teker végig a result set-en (esetleg kétszer lekérdezve az adatokat), vagy valami más módon kérdezi le, de mindegy, ahogyan használod, annak nincs értelme, ha minden adat kell, akkor fetchAll() és kész (nem mindig jó mindent előre betölteni sem, helyzet függő, de a kódodban elvágod annak a lehetőségét, hogy máshogyan lehessen dönteni).

 

A parancsból találgatni megint nem szerencsés, ahogyan végzed pl. a SELECT-nek az ellenőrzését, máris számtalan hibára futhat: white space-szel kezdődik a string, miért ne, kisbetűvel írom, miért ne?

 

Az sql_return($sql)-ben megszámolod az eredményeket, de ez nem szerencsés, ha sokszor sok elem jön vissza, hiszen lassú lesz, illetve nem gondolom, hogy ennek a függvénynek a feladata eldönteni, mikor ad vissza tömböt, és mikor egy elemet (néha meg a lastInsertId-t, vagy éppen a rowCount()-ot próbálja ).

 

Az sql_array() mire van?

 

Az sql_error()-t meg el kell felejteni ebben a formában (debug_backtrace() kézzel használva production kódban 2015-ben?).

 

Ezek olyan dolgok, amelyek csak első pillantásra szembe ötlenek, ettől több probléma is van ezzel, illetve minden olyan kód, amiben alkalmazva vannak ezek a függvények és technikák, szintén hibásak.

[kléni]

Kinek a pap, kinek a papné. Egyértelműen nem az volt a célom, hogy bárkivel is megosszam ezt a kódot azért, hogy ő is használja. Akkor talán egy normális class-t írok hozzá, több funkcióval. De ezek az fn-ok tökéletesek arra, amire én megírtam őket. Lehetséges, hogy te nem értetted meg, ez mire jó, de nekem se sikerült rájönni, a linkelt kód mit csinál.

Összegezzük tehát, hol tartunk:

- Ha szerinted az MSSql jobb, használd azt. Nekem a sulis Access feladatoknál is elég volt belőle.

- Ha a PHP valami létfontosságú dolgot nem támogat, de van rá kiskapu, nyilván azt ki kell használni. Ha a linkelt kód erre is jó, hajrá.

- Eddig a PDO nekem mindenre jó volt, amire kellett. Nem mondom, hogy az alap PDO a legszebb, legrövidebb, de hát ez van. Épp ezért írtam egy fn-t rá, ami lerövidíti, és nem kell a PDO fn-jaivel mindig vacakolnom.

 

De nézzük még a csoda függvényeimet. Ess neki úgy is, hogy tudod, nem másnak van szánva a kód.

Semmi szükség nincs a sikertelen kapcsolódásnál másra, mint kiírja hogy baj van, és lelője a további futást. Írhattam volna én itt csodás hibaoldalt, meg hibakezelő dolgokat, de erre nincs szükség. Ilyen amúgy is csak akkor jelentkezik, amikor nincs bekapcsolva a MySql, vagy még nem töltöttem fel a táblákat bele.

Hogy lefutott-e helyesen a késér, azt tényleg idegesítő lenne egyesével ellenőrizgetni. De éppen erre írtam egy külön fn-t, ami leellenőrzi, és még hozzáadja a szükséges adatokat is, mert az alap hibaüzenetben nincsenek benne.

Nem teszek space-t a SELECT elé, és nem írom kisbetűvel. Ezen kár problémázni.

Az sql_return azt csinálja, amit én akarok. Egy weboldalnál én nem fogok milliónyi sorokat használni. A lehető legkevesebb sort kell lekérdezni, és magán az oldalon is lehető legkevesebb lekérdezés legyen. Felesleges adatokat ne kérdezzünk le. A visszaadott érték attól függ, milyen "környezetben" hívtam meg az fn-t. Nyilván tudni fogom, mikor várok csak egy, és mikor 50 sort. Ha csak valamilyen adat lekérdezésére kell, mondjuk egy cikk címe, tartalma, akkor 1 sort ad vissza. Simán használhatom így:

$a = sql("SELECT * FROM cikk WHERE id = ?", 5);

echo $a->cim;

A visszaadott számok annyira nem bonyolultak. INSERT esetén csak a legutolsó ID kellhet, UPDATE esetén a módosított sorok száma, SELECT-nél pedig csak maguk a sorok. Minek írjak egy sql_lastinsertid()-t is, amikor egyszerűen visszakaphatom így is?

Az sql_array pont arra van, hogyha pl. az első 20 cikket ki akarom listázni, de 0, vagy csak 1 cikk van, akkor mindenképpen array-t kapjak vissza, így a későbbiekben nem kell azon tűnődni, a $cikkek egy tömb, vagy objektum. Hogy mikor mit kell használni, azt tudni fogom.

Az sql_error() fn-ban mi a baj? Pontosan azt teszi, amit én akarok: kiírja, hol hívtam meg az sql()-t, egyszerűen megnyitom a fájt, és megnézem mit írtam el. Amikor megírtam a kódot, elég sokat keresgettem, hogyan lehet másképpen megoldani, hogy a hibaüzenetben ne azt a sort írja ki, ahol maga a hiba keletkezett, hanem ahol meg lett hívva az sql(). Ennél jobb megoldást nem találtam, már pedig ez kell nekem, ha külön fn-t akarok használni az sql-es dolgokra.

 

Hibások, mert te másképp oldottad volna meg? Szerintem csak másképpen gondolkozunk. Én nem szeretem, ha feleslegesen kell többet írnom, hogy a rövidebb is mindenre jó, ami nekem kell. Teljes mértékben átlátom még az ennél bonyolultabb kusza kódokat is, és gondolkodás nélkül használok break-ot is bárhol. Tudnék én olyan kódot is írni, ami bárki számára átlátható lenne, de akkor +20 fn név lenne, más megoldásokat kellene használni, és nem az volt a célom, hogy egy teljes keretrendszert írjak, vagy valami CMS-t. Ez jól működik mindenre, ami kell, akkor meg mi a baj? Magukat az fn-eket nem kell olvasgatni. Ha akarnám, hogy más használja, leírom nekik, hogyan működnek, ő megjegyzi, és használja. Megjegyezni egy rakat függvény nevet nekem nem nehezebb, mint a lehetséges variációkat megtanulni. Szerintem ha kezdetben neked is csak azt mutatom meg, hogy használd, nem ilyen ennyire heves reakciód lett volna, és sokkal többet értettél volna meg.

[Pjotr]

Kinek a pap, kinek a papné. Egyértelműen nem az volt a célom, hogy bárkivel is megosszam ezt a kódot azért, hogy ő is használja. Akkor talán egy normális class-t írok hozzá, több funkcióval. De ezek az fn-ok tökéletesek arra, amire én megírtam őket. Lehetséges, hogy te nem értetted meg, ez mire jó, de nekem se sikerült rájönni, a linkelt kód mit csinál.

De nézzük még a csoda függvényeimet. Ess neki úgy is, hogy tudod, nem másnak van szánva a kód.

Én értem, mit csinál a kódot, de csak azért, mert belekukkantottam. Kívülről egyik függvény sem mond magáról semmit.

 

Semmi szükség nincs a sikertelen kapcsolódásnál másra, mint kiírja hogy baj van, és lelője a további futást. Írhattam volna én itt csodás hibaoldalt, meg hibakezelő dolgokat, de erre nincs szükség.

De, van, máshol is előfordulhat hasonló jellegű hiba, akkor azt is helyben lekezeled így? Ha 5 helyen fordulhat elő, akkor ötször csinálod meg a kezelést? Nem jobb lenne egyszer?

 

Nem teszek space-t a SELECT elé, és nem írom kisbetűvel. Ezen kár problémázni.

Utolsó mondatok egyike.

 

Az sql_return azt csinálja, amit én akarok. Egy weboldalnál én nem fogok milliónyi sorokat használni. A lehető legkevesebb sort kell lekérdezni, és magán az oldalon is lehető legkevesebb lekérdezés legyen. Felesleges adatokat ne kérdezzünk le. A visszaadott érték attól függ, milyen "környezetben" hívtam meg az fn-t. Nyilván tudni fogom, mikor várok csak egy, és mikor 50 sort. Ha csak valamilyen adat lekérdezésére kell, mondjuk egy cikk címe, tartalma, akkor 1 sort ad vissza. Simán használhatom így:

$a = sql("SELECT * FROM cikk WHERE id = ?", 5);

echo $a->cim;

A visszaadott számok annyira nem bonyolultak. INSERT esetén csak a legutolsó ID kellhet, UPDATE esetén a módosított sorok száma, SELECT-nél pedig csak maguk a sorok. Minek írjak egy sql_lastinsertid()-t is, amikor egyszerűen visszakaphatom így is?

Az sql_array pont arra van, hogyha pl. az első 20 cikket ki akarom listázni, de 0, vagy csak 1 cikk van, akkor mindenképpen array-t kapjak vissza, így a későbbiekben nem kell azon tűnődni, a $cikkek egy tömb, vagy objektum. Hogy mikor mit kell használni, azt tudni fogom.

Ezek nálam a fekete mágia kategóriába esnek, ezek inkább ízlés dolga talán, de ebben sem vagyok teljesen biztos.

 

Az sql_error() fn-ban mi a baj? Pontosan azt teszi, amit én akarok: kiírja, hol hívtam meg az sql()-t, egyszerűen megnyitom a fájt, és megnézem mit írtam el.

Hibát nem így "generálunk" és kezelünk. Mindenképp exception-ökkel kell használni a PDO-t, amennyiben szeretnéd használni a stack trace-t, akkor a PDO által dobott exception-ben benne van minden adat, nem kell ennyit bűvészkedni (azt hittem, fontos, mennyit kell gépelni).

 

Hibások, mert te másképp oldottad volna meg? Szerintem csak másképpen gondolkozunk. Én nem szeretem, ha feleslegesen kell többet írnom, hogy a rövidebb is mindenre jó, ami nekem kell. Teljes mértékben átlátom még az ennél bonyolultabb kusza kódokat is, és gondolkodás nélkül használok break-ot is bárhol. Tudnék én olyan kódot is írni, ami bárki számára átlátható lenne, de akkor +20 fn név lenne, más megoldásokat kellene használni, és nem az volt a célom, hogy egy teljes keretrendszert írjak, vagy valami CMS-t. Ez jól működik mindenre, ami kell, akkor meg mi a baj? Magukat az fn-eket nem kell olvasgatni. Ha akarnám, hogy más használja, leírom nekik, hogyan működnek, ő megjegyzi, és használja. Megjegyezni egy rakat függvény nevet nekem nem nehezebb, mint a lehetséges variációkat megtanulni. Szerintem ha kezdetben neked is csak azt mutatom meg, hogy használd, nem ilyen ennyire heves reakciód lett volna, és sokkal többet értettél volna meg.

Nem azért hibás, mert másképp látom, hanem mert technikailag rossz megoldásokkal van tele, ez nem szubjektív vélemény, gyakorlatilag tény. Dokumentációt nem írunk, ha nem muszáj, egyszerűbb önmagát dokumentáló kódot írni.

 

Valamiért azt gondolom, nem szoftverfejlesztésből élsz.