ugrás a tartalomhoz

Full OOP PHP kód, nem túlzás egy kicsit ?

Webdev · 2011. Júl. 13. (Sze), 18.53
Sziasztok!

PHP keretrendszert szeretnék választani. Régóta érlelődött már bennem ez a gondolat. Igazából konkrét feladatra, ahol fontos a sebesség, de úgy általában is szeretnék egy keretrendszert mélyebben megismerni, mert hiába, "divat" lett keretrendszerben programozni.

A Zend keretrendszer kódjába néztem bele, és néhány hozzá kapcsolódó tutorialba.

Őszintén, elképedtem :)

Egy egyszerű MySql lekérdezés is már több osztályból, függvényből áll. Amit el nem tudok képzelni, hogy miért jobb ennél:
$query = mysql_query("SELECT * FROM table WHERE id = '".(int)$id."'"); ?


Amin teljesen kibuktam, hogy már egy formot is egy tucat függvénnyel állítanak elő. Senki se mondja azt, hogy ez vetekedhet egy HTML formmal, és sebességével !

Mégis hogyan lehet egy ilyen keretrendszerrel gyors, dinamikus oldalakat előállítani, pláne ahol fontos a sebesség, mert pl. sokan csüngnek az oldalon ?

Azt aláírom, hogy nagyon jó az MVC megközelítés, és ehhez kapcsolódó osztályok (egyszerű adatbázis,user auth osztály), de hogy minden egyes folyamatra osztályt alkalmazni... ez egy kicsit sok nekem.

Oké, idővel megtudnám érteni, és használni is, és jó mások minőségi kódját használni, de ... így meglátásom szerint egy böszme nagy, nehéz rendszer lesz, ami köti az ebet akaróhoz.

Most rátaláltam a CodeIgniterre, ami egy kissé barátságosabbnak tűnik, de még nem volt időm bővebben belenézni a kódjába... csak tutorialba.

Szerintetek nem túlzás ráerőltetni a PHP-ra a full OOP megközelítést? Hiszen ez mégsem C# ami egy PC alapú, és a teljes erőforrás adott a kód végrehajtására!!!

Mit ajánlotok nekem, ami OOP MVC felépítés, de mégsem viszi túlzásba.
CodeIgniter szerintetek jó? Még ezt a Kohana-t is írják több helyen. Szerintetek?

Köszönöm a segítséget, és hogy végigolvastátok a hosszú eszmefuttatásomat...
‹ PHP RegExp személynévre Kereső készítés elvei ›
 ■
1

Már többször volt erről szó,

Hidvégi Gábor · 2011. Júl. 13. (Sze), 19.03
Már többször volt erről szó, például ebben a fórumtémában, ami most is aktív.
2

Gyors, Karbantartható, Fejlesztési idő

Poetro · 2011. Júl. 13. (Sze), 19.12
A fenti kettő közül nem fog mind teljesülni. Ha sebességre gyúrsz, akkor valószínűleg bukod a karbantarthatóságot, ha egyszerűen karbantartható kódot akarsz, akkor meg a sebességet. El kell dönteni, hogy neked melyik a fontos. És nagyon fontos a fejlesztési idő is. Ha valaki ismer egy keretrendszert, pillanatok alatt összedob neked egy közepesen összetett oldalt, ami karbantartható lesz a keretrendszer adta körülmények miatt, viszont nem lesz olyan gyors, mintha nem használna semmit. Ha nem használsz keretrendszert, akkor pedig a fejlesztési időd fog jócskán megnőni, mivel minden ponton fel kell majd találni a kereket.
40

+1

fchris82 · 2011. Júl. 14. (Cs), 20.36
Ajánlom itt sokak figyelmébe az alábbi linkeket:
Keretrendszer használata pro és kontra

After all! What is this no-framework? - hozzászólásom

Php - ORM rendszerek - hozzászólásom

Azon jót nevettem, mikor egyesek azzal jönnek, hogy "de mi van, ha megszűnik a fejlesztés, és kiszolgáltatott leszek egy harmadik félnek?" :D :D :D Naponta álmatlan éjszakáim vannak, hogy leáll a ZF, Symfony, jQuery fejlesztése, sőt, a PHP is bármikor megszűnhet :D Na, akkor mi lesz?

A lényeg: keretrendszer használata -> idő. Az idő meg pénz. Sok esetben nagyon sok pénz. És jobb 1 hónap alatt kijönni vmi félkész vacakkal, mint tökéletesen fejleszteni és kijönni fél év múlva. Egyrészt, lehet, hogy nem működik az üzleti elképzelés, ha jól tudom, 10-ből csak 1 startup lesz sikeres, tehát 9 BEBUKIK, vagy messze nem hozza a várt eredményt. 6 hónap alatt inkább csinálok meg 6 munkát, ami "lassú", mint 1-et, ami gyors. Egyébként meg ha elkezd nőni a látogatottság, lehet optimalizálni, cache-elni, stb, stb, aztán pislogni, hogy még így is 2 hónap fejlesztéssel, jobb, rugalmasabb, és ugyanolyan gyors oldal készült, mint 6 hónap egyedi fejlesztéssel. A fenti az vmi elméleti huszárkodás, amit én mondok, meg 11 év tapasztalata. Persze mindenki azt csinál, amit akar :D
41

+1

inf · 2011. Júl. 14. (Cs), 20.41
+1, hát jah, ez a döntés kőkeményen a pénzről szól, ezért láttam értelmetlennek a vitát. Ha megfizetnek én is szívesen fejlesztek keretrendszert, de általában a vevőnek azonnal kell minden a lehető legolcsóbban...
3

Kohana vs. CodeIgniter

NiGGa · 2011. Júl. 13. (Sze), 20.08
Eddig CodeIgniterrel dolgoztam, amit én olvastam az az, hogy már már a tökéletes keretrendszer, ha nem akarod, hogy mindent kigeneráljon és megcsináljon helyetted.
Ahol most dolgozok itt Kohana a kötelező. Nem egyszerű átállni, igaz hogy ez is a CI-ből lett. De ég és föld. Kohaha szar a route-olás, jó az ORM, meg néhány plusz osztály amit ad.
Nem hinném, hogy amit a példaként hozol fel, az ennél rövidebb ORM::factory("table")->where('id','=',$id)->find(); gyorsabb, vagy könnyebb használni.
Csinálj meg egy komplett projektet mindkettővel, és meglátod, miért kell a sok osztály.
Példa: 2 adatbázisod van, de mindkettőből egyformán tudsz dolgozni, mint interface.
A query() az query() mssql-ben, postgresql-ben és mysql-ben is.
Jön majd a CodeTrine (CodeIgniter és DocTrine hibrid) az lesz jó.
4

nem a túlzás a cél

tiku I tikaszvince · 2011. Júl. 13. (Sze), 20.39
Ne azért kezdj el keretrendszert keresni mert divatnak látod! Ha így fogsz neki, akkor mindegyikben csak azt fogod keresni, hogy miért nem jó.

Egyik keretrendszernek sem a túlzás a célja. A cél az, hogy a fejlesztőknek spóroljanak időt.

Személy szerint én pont Zend Framework-kel dolgoztam sokat, és épp az általad kifogásolt Zend_Form részt tartom belőle a legnagyobb jóságnak. Egy komolyabb webalkalmazás komplex űrlap kezelés nélkül ma már elképzelhetetlen. A Zend_Form-mal nem csak az űrlap és elemeinke megjelenítését tudod kezelni, hanem egy darab épített objektummal végzed felhasználótól kapott adatok szűrését ÉS ellenőrzését.

DB: mi van ha kitalálod, hogy MySQL-ről váltasz SQLite-ra esetleg PostgreSql-re? Meg kell keresned a kódodban az összes lekérdezést, módosítanod kell a mysql_query függvény hívást a választott adatbáziskezelőnek megfelelőre. De feltételezem írsz egy függvényt, amin átengeded az összes query-t. De akkor még mindig ott van az adatbázis kezelők különböző SQL dialektusainak problémája.

Az összes keretrendszerben fogsz találni valami adatbázis réteget, amik mind-mind teljes mértékig OOP megközelítéssel készülnek. Mindegyiknek egyik fő célja, hogy elfedje előled a háttérben használt adatbázis kezelő sajátosságait, ezzel is megkönnyíti neked, hogy rugalmasabb kódot írhass. Segítenek szabályos és minél biztonságosabb SQL utasítások összeállításában, ezzel védik az általad kezelt adatokat, és áttételesen neked spórolnak időt.

Ha egyszerűen költség oldalról nézzük a dolgot: ha egy saját (keret)rendszert írsz, akkor rengeteg dolgot neked kell megírni, ahelyett hogy "beleülnél a tutiba" és elkezdenéd használni azt, amit rengeteg ember fejleszt, még többen, nap mint nap tesztelnek. Ezeknek a megírása mind rengeteg idő. Az idő pedig, mint tudjuk, pénz.

Az hogy egy projektben használj-e keretrendszert, és melyiket, nagyban függ a projekt méretétől, a benne dolgozók számától. Ha a projekteden egyedül dolgozol, és úgy látod, hogy ez középtávon nem is fog változni, és nem érzed szükségét akkor ne használj keretrendszert. Ennyi.
6

Viszont ha elkezdesz

csabessz47 · 2011. Júl. 13. (Sze), 21.08
Viszont ha elkezdesz fejleszteni egy keretrendszert, sokat tanulhatsz ha nem vagy mondjuk pro :).
Legalább is nekem ez a tapasztalatom.

Viszont ha nem akarsz tanulni, vagy nincs időd, nekem a CodeIgniter volt a legmegfelelőbb.
7

Viszont ha elkezdesz

inf · 2011. Júl. 13. (Sze), 22.48
Viszont ha elkezdesz könyveket olvasni, akkor még többet tanulhatsz... :-)
9

Persze, én is minden nyelvet

csabessz47 · 2011. Júl. 14. (Cs), 10.14
Persze, én is minden nyelvet vagy újdonságot azzal kezdtem. Ha nem is könyvekkel, legalább neten található leírásokkal. De ha utána nem gyakorolsz, akkor nagy esély van rá, hogy eltűnjön az egész :)

Egyébként nem muszáj használni a keretrendszeres osztályokat. Nekem is van olyan munkám, ahol CodeIgniterben nem a keretrendszer osztályait használtam, hanem mysqli-t. Ha tudom, hogy a MySQL nem fog változni pl SQLite-ra vagy akármire, szerintem nyugodtan lehet használni akár még sajátot is.
8

pont ez a kérdésem

nistvan · 2011. Júl. 14. (Cs), 00.12
Az hogy egy projektben használj-e keretrendszert, és melyiket, nagyban függ a projekt méretétől, a benne dolgozók számától. Ha a projekteden egyedül dolgozol, és úgy látod, hogy ez középtávon nem is fog változni, és nem érzed szükségét akkor ne használj keretrendszert. Ennyi.


Pont ez a kérdés merült fel bennem a napokban, és keresgéltem utána neten, de igazi választ nem találtam. Saját projektemmel kapcsolatban: elég nehéz egy félig még tervezés alatt álló projekt méretét pontosan megbecsülni, de minek után a tervezett funkciók jó része már a fejemben készen van, kezdeti domain modellem is elkészült. Ez alapján _minimum_ 25 saját osztállyal számolok abban az esetben, ha a "keretrendszert" magam készítem el. És ebben még nem feltétlenül vannak benne például az adatbázis kezelő osztályok, mivel azokat is úgy kell elkészítenem, hogy több DB típust is támogassanak. Tehát egy adatbázisréteget kell létrehoznom. Ez még tán menne is, de milyen áron?

Visszatérve, a weboldal hasonló lenne az egyetemeken gyakran használt moodle rendszerhez. Persze nem akarom újra feltalálni a dolgot, valójában csak az oldal célja egyezik meg. Iskolák, kurzusok, projektek, naptárbejegyzések, fórumok, feltöltések, tesztek. Nagyjából ezeket a funkciókat kell ellátnia. Jól érzem, hogy egy ilyen volumenű projekthez már érdemes keretrendszert használni? Először azért gondoltam a saját OOP megvalósításban, mert szakdolgozatnak készül, így nem tudom, hogy fogadja majd a bizottság és a bírák, hogy egy "kész" rendszert használtam. Magyarázhatom, hogy annak megismerése felért egy saját rendszer írásával, de tudjuk milyenek a tanárok a területen, amihez nem értenek.

Tehát a kérdés, ilyen volumenű projekthez ajánljátok a keretrendszereket? És melyiket? (figyelembe véve, hogy ha később az utam abba az irányba sodor, hogy PHP-ben akarok fejleszteni, akkor ebből a szempontból ne olyat tanuljak, amit aztán nem tudok hasznosítani a cégeknél.)
5

PHP keretrendszert szeretnék

inf · 2011. Júl. 13. (Sze), 20.57
PHP keretrendszert szeretnék választani.

zend.
10

yii

Greg · 2011. Júl. 14. (Cs), 11.53
nekem az alatalam eddig hasznalt php keretrendszerek kozul o tunt a legjobb valasztasnak. gyors. nincs tulbonyolitva. gyors vele a fejlesztes. konnyen kiegeszitheto. nekem ezeken felul nincs is szuksegem masra.
11

Őszintén szólva nem rajongok

bb0072 · 2011. Júl. 14. (Cs), 12.49
Őszintén szólva nem rajongok a keretrendszerekért. Az a CMS, amit többen közösen fejlesztünk, évekkel ezelőtt lett integrálva a Zend FrameWork akkori verziójához, amit most már frissíteni sem tudunk, mert az integrálás nem volt kellőképpen átgondolt anno.

Az a ZF olyan alapszintű bugokat tartalmaz, hogy egy query végrehajtása után nem lehet debug célzattal kinyerni, hogy mi is volt az a tényleges query ami az adatbázison lefutott!!! Ha pedig elkezdesz tukálni a ZF core-ban, hogy kijavíts egy hibát, hamar rájössz, hogy kb. 3 nap munka lesz. Nota bene: a keretrendszereket is csak programozók írják, egyik sem a bölcsek köve, viszont ha bug van bennük, nagyot szívsz vele.

Ennél is komolyabb probléma a hatékonyság. Egyetlen query végrehajtásához is inicializál vagy egy tucat osztályt, amelyek abstract osztályoktól örökölnek, amik maguk is abstract osztályok kiterjesztései, interface-ekkel és egyedi exception handlerekkel. Egy komplett oldal kiszolgálása során include-ol vagy 1000 file-t. Nagy forgalmú rendszereket ez elég gyorsan taccsra tesz.
12

nem értem, hogy a "nem

tiku I tikaszvince · 2011. Júl. 14. (Cs), 13.07
nem értem, hogy a "nem kellőképpen átgondolt" integrálás miért a választott keretrendszer hibája? Ha ész nélkül kezdesz el dolgozni, akkor mindegy melyik rendszert választod, csak az orbitális szívás lesz belőle.
13

+1

inf · 2011. Júl. 14. (Cs), 13.12
+1
Nekem eddig egyébként pozitív élményeim vannak zenddel kapcsolatban. (Bár csak nem rég kezdtem bele a használatába.)
Az sql-ek loggolását meg gondolom meg lehet oldani dependency injectionnel és az aktuális adatbázis kezelő osztály kiterjesztésével.

Egy komplett oldal kiszolgálása során include-ol vagy 1000 file-t.

Ezt elég nehezen hiszem el, mivel a keretrendszer kb 2800 fájlból áll, aminek nagy része különböző extrákhoz kapcsolódik, mint pl pdf generálás, stb...
15

Ezt elég nehezen hiszem

H.Z. v2 · 2011. Júl. 14. (Cs), 13.41
Ezt elég nehezen hiszem el,

Költői túlzás, mint fogalom, mond valamit? ;-)
Belelapozva a propel és a kohana kódjába, valahogy égnek állt a hajam maradéka, hogy mennyi mindent kell betölteni ahhoz, hogy megjelenjen egy oldal...
16

Költői túlzás, mint fogalom,

inf · 2011. Júl. 14. (Cs), 14.36
Költői túlzás, mint fogalom, mond valamit? ;-)

Hát nem tűnt versnek, amit írt...

Nem néztem meg túl sok keretrendszer forrását, az alapján választottam, amit neten olvasgattam ezekről a rendszerekről. Zend a felépítésében körülbelül olyan, mint ahogyan én is megírnék egy ilyen rendszert. Ezért tetszik. A másik, ami miatt bejön az, hogy lehet IDE-vel használni.
14

Szerintem nem ezt írta

H.Z. v2 · 2011. Júl. 14. (Cs), 13.38
Az én olvasatomban azt jelenti bb0072 hozzászólásának eleje, hogy egy külső keretrendszert választottak, ami teli van hibákkal, de már nem jön hozzá javítás -> ha valami gáz van, akkor magukra maradnak egy belülről ismeretlen rendszerrel.
Ha ugyanez saját fejlesztés, akkor esélyes, hogy lesz ember, aki javítja ezeket a hibákat.

A hatékonyság kapcsán meg nagyjából egyetértek vele, bár már többször a fejemhez lett vágva, hogy túl sokat aggódok a performancia miatt... :-)
17

Ez a keretrendszer és a

inf · 2011. Júl. 14. (Cs), 14.54
Ez a keretrendszer és a sebesség kapcsolata szerintem találgatás. Mutassatok példát, ahol leméritek valaminek a sebességét keretrendszerrel meg anélkül.
Egyébként szerintem vannak megoldások arra, hogy a beszúrt php fájlokat a memóriában tartsa a rendszer. Ez már szimplán azzal megoldható, hogy a megfelelő típusú winchestert teszi bele a szerverbe az ember. (Nem vagyok üzemeltetési szakértő.)
18

Az operációs rendszerek

Hidvégi Gábor · 2011. Júl. 14. (Cs), 15.04
Az operációs rendszerek alapból gyorstárazzák az utoljára használt fájlokat.
19

Ahm, én hibrid ssd-re

inf · 2011. Júl. 14. (Cs), 15.09
Ahm, én hibrid ssd-re gondoltam, abban is van valamekkora memória a gyakran használt fájloknak.
20

Hasonlóan látom én is a

Hidvégi Gábor · 2011. Júl. 14. (Cs), 15.10
Hasonlóan látom én is a dolgokat. Ráadásul sokminden van, ami nem tervezhető előre, és az ember megragad egy X verziónál, vagy egyszerűen nem fejlesztik tovább az adott keretrendszert. Vagy találsz egy hibát, jelzed a fejlesztőknek, aztán meg esetleg hetekig várhatsz, amíg kijavítják. Magyarul egy harmadik féltől való függés nem biztos, hogy a legegészségesebb.

Emellett fontos dolog a tanulás (amit más is említett): ha egyből valamilyen keretrendszerrel kezdesz, azt fogod tudni használni, de nem tudod, hogy mi miért van úgy, és ha már egy kicsikét is bonyolultabb problémát kell megoldani, széttárod a kezed, hogy erre a keretrendszer nem alkalmas.
21

Vagy találsz egy hibát,

Joó Ádám · 2011. Júl. 14. (Cs), 15.39
Vagy találsz egy hibát, jelzed a fejlesztőknek, aztán meg esetleg hetekig várhatsz, amíg kijavítják. Magyarul egy harmadik féltől való függés nem biztos, hogy a legegészségesebb.


Ideiglenesen te is megfoltozhatod, mondjuk kiterjesztve az adott osztályt. És ha már ott tartasz, el is küldheted a fejlesztőknek a foltot.
24

Ez igaz, de nem ez a lényeg.

Hidvégi Gábor · 2011. Júl. 14. (Cs), 17.32
Ez igaz, de nem ez a lényeg. Meg ugye azt a kódot át kell látni, megérteni, átnézni, hogy a javítás mire van hatással, szóval nem egyszerű. Tudom, mert már csináltam ilyet, nem egyszer fordult már elő, hogy egyszerűbb volt nulláról megírni valamit, mint a meglevő osztályokat hegeszteni, amelyek hat-nyolcszoros öröklődésen keresztül érték el a végleges formájukat.
22

témaindító

Webdev · 2011. Júl. 14. (Cs), 16.40
Sziasztok!

Köszönöm a sok választ.
Ne haragudjatok, ha már volt ilyen téma. Szoktam olvasni a topikokat, de nem annyira emlékeztem ilyenre, az a másik téma elkerülte a figyelmemet.

"Saját rendszer" - Még nem érzem magam annyira jónak, hogy biztonságosan megírjak egy ilyet. De ha megismerek egy keretrendszert mélyebben, utána szóba jöhet.

"Ne azért kezdj el keretrendszert keresni mert divatnak látod!"
Egy másik fórumon olvastam, hogy egy valamire való webes alkalmazás keretrendszerben készül, egy sima, nem keretrendszeres kódot eladni egyenesen pofátlanság, büntetni kéne érte a programozót.

Igen, mindenképpen hasznos a debug, kivételkezelés is a keretrendszerekben, hogy nem fatal-error, hanem egy részletes hibaleírás (pl. kohana).

Valószínűleg a CodeIgniter és a Kohana közül választok.
Mégsem annyira objektum tenger... könnyebben emészthető, és hát mégis a két leggyorsabb, legrugalmasabb keretrendszerről beszélünk.
25

Egy másik fórumon olvastam,

H.Z. v2 · 2011. Júl. 14. (Cs), 17.32
Egy másik fórumon olvastam, hogy egy valamire való webes alkalmazás keretrendszerben készül, egy sima, nem keretrendszeres kódot eladni egyenesen pofátlanság, büntetni kéne érte a programozót.


Amellett, hogy ebben a formában nagyon nem tudok egyetérteni vele, volna egy fogadásom, hogy p*.hu volt a fórum... :-))
Persze: egymagad fejlesztesz és eladod a rendszert, rendesen megnehezíted annak a dolgát, aki utánad bele akar nyúlni esetleg. Ha nagyon rosszindulatú akarok lenni, akkor azt mondom, hogy többek közt ezért is érdemes saját keretet használni. Kisebb az esélye, hogy legközelebb pusztán azért adják másnak a módosítási munkát, mert olcsóbban vállalja, mint te. ;-)
28

Idővel saját keretrendszer

Webdev · 2011. Júl. 14. (Cs), 17.57
Ha úgy alakul, idővel írok egy saját rendszert. Először egy kész keretrendszerben gondolkodtam ugye, mert szeretném látni más kódját, mások logikáját, megvalósítását, trükkjeit.

Egyébként, ez most nem a p*.hu :) Hanem a s*.forum.hu, egy "php framework" topikban volt egy nagyon hosszú eszmefuttatás a keretrendszerekről. Nem linkelem, nem lenne korrekt dolog.
55

"Egyébként, ez most nem a p*.hu :) Hanem a s*.forum.hu, egy "ph"

Greg · 2011. Júl. 15. (P), 11.17
azert olyan troll velemenyere adni aki azota onnan ki is lett tiltva nem okos dolog szerintem.
az a tag ossze-vissza irkalt. szerinte a legjobb framework a symfony 2, de meg nem probalta ki :). azert ugy velemenyt alkotni valamirol hogy ki se probalja, sokat elarul szerintem.
23

Amin teljesen kibuktam, hogy

phtamas · 2011. Júl. 14. (Cs), 17.22
Amin teljesen kibuktam, hogy már egy formot is egy tucat függvénnyel állítanak elő. Senki se mondja azt, hogy ez vetekedhet egy HTML formmal, és sebességével !

Nem mondja senki :)

Képzelj el egy összetettebb üzleti alkalmazást, amelyben több tucat (vagy több száz) különböző űrlapot kell kezelned. Az egyes űrlapok konkrét felépítése változzon attól függően, hogy az adott felhasználónak milyen jogosultságai vannak. És képzeld el, hogy amikor elkészítetted mindet HTML-ben, akkor jön az UX-guru, és szól, hogy meg kell változtatni az űrlapok elrendezését. Amihez bele kell nyúlni a HTML kódba.
Szóval van létjogosultsága a Form objektumoknak. Egy egyszerű bejelentkező űrlaphoz speciel nem biztos hogy használnám.

Egy egyszerű MySql lekérdezés is már több osztályból, függvényből áll.


A Zend_Db-t akkor érdemes használni, ha:
- Adatbázis-absztrakcióra van szükséged. Például szeretnél egy újrahasznosítható akalmazásmodult vagy komplett alkalmazást (fórummotor, blogmotor, CMS ...) írni, ami többféle backenddel is képes együttműködni.
- Futási időben dinamikusan összerakott lekérdezéseket akarsz futtatni.
- Szükséged van a Zend_Db_Table által nyújtott funkciókra (nem részletezem, benne van a manualban).
26

Én elképzeltem...

H.Z. v2 · 2011. Júl. 14. (Cs), 17.35
Képzelj el egy összetettebb üzleti alkalmazást, amelyben több tucat (vagy több száz) különböző űrlapot kell kezelned.

Én elképzeltem, de őszintén szólva ilyen célra már nem használnék PHP-t. Java, .net, ilyesmi...
Persze ez csak az én véleményem.
27

Én elképzeltem, de őszintén

phtamas · 2011. Júl. 14. (Cs), 17.55
Én elképzeltem, de őszintén szólva ilyen célra már nem használnék PHP-t.

Jogos. Ha rajtam múlik, én sem. És a frontend is inkább Flex (ExtJS, stb.) lenne mint sima HTML. De ettől függetlenül készülnek ilyen alkalmazások PHP/ZF platformon.
29

Az ExtJS-t komolyabb munkához

Hidvégi Gábor · 2011. Júl. 14. (Cs), 18.17
Az ExtJS-t komolyabb munkához semmiképp sem ajánlanám (komolytalanabbhoz se), mi most szabadulunk meg tőle szép lassan. Ráadásul a licensze sem olcsó, ha fizetős megrendeléshez szeretnéd felhasználni.
31

Köszönöm a tippet! Résen

phtamas · 2011. Júl. 14. (Cs), 18.45
Köszönöm a tippet! Résen leszek :)
39

Új szál

fchris82 · 2011. Júl. 14. (Cs), 20.09
Szia Gábor!

Itt indítottam egy új szálat: http://weblabor.hu/forumok/temak/109418 Kifejtenéd a véleményedet?
30

Mi vagyunk hülyék

Poetro · 2011. Júl. 14. (Cs), 18.38
Tudom, mi vagyunk hülyék, hogy a napi több millió oldalletöltéssel rendelkező Examiner.com-ot átraktuk ColdFusion-ről (Java) Drupal-ra. Azóta gyorsabb az oldal, kevesebb szerver kell, és a felhasználók is boldogabbak, mivel rugalmasabb lett a rendszer.
32

Én mindig is szkeptikus

Hidvégi Gábor · 2011. Júl. 14. (Cs), 19.16
Én mindig is szkeptikus voltam a java sebességével kapcsolatban, de java programozók mindig nagyon győzködtek, sőt, azt is állították, hogy egy jó fordítóval akár gyorsabb kódot lehet generálni, mint mondjuk C-ből.
57

Nehezen győznek meg róla,

Joó Ádám · 2011. Júl. 15. (P), 18.08
Nehezen győznek meg róla, hogy az automatikus memóriakezelés gyorsabb lehet, mint a kézi. Sok egyéb koncepcionális különbségről nem is beszélve. De ez is csak egy hitvita.
34

Azért nekem van egy olyan

H.Z. v2 · 2011. Júl. 14. (Cs), 19.36
Azért nekem van egy olyan érzésem, hogy ez nem annyira a java vs PHP történetről szól.

class Z {
        int xx(){ return 0; }
}

public class X {
        public static void main(String args[]){
        int n,m;
        Z z;

        for(n=0; n<10000000; n++){
                z=new Z(); m=z.xx();
                z=new Z(); m=z.xx();
                z=new Z(); m=z.xx();
                z=new Z(); m=z.xx();
                z=new Z(); m=z.xx();
        }
        System.out.println("Kész"+n);
        }
}



<?php
class Z {
        function xx(){ return 0; }
}


        for($n=0; $n<1000000; $n++){
                $z=new Z(); $m=$z->xx();
                $z=new Z(); $m=$z->xx();
                $z=new Z(); $m=$z->xx();
                $z=new Z(); $m=$z->xx();
                $z=new Z(); $m=$z->xx();
        }
        echo "Kész ",$n;
Tudom, nem sokat jelent, de a két kód nagyjából ugyanazt csinálja. A java 0.2mp, a PHP 5mp futásidővel.
36

Természetesen nem

Poetro · 2011. Júl. 14. (Cs), 19.37
Természetesen nem a Java vs. PHP téma a lényeg, hanem hogy majdnem teljesen mindegy hogy milyen nyelven valósítod meg, általában úgysem az lesz a szűk keresztmetszet, hanem az I/O. Legyen az fájlrendszer, adatbázis, hálózat. Ha ezeket jól valósítod meg, akkor máris sokkal gyorsabb lett az alkalmazásod. Arra akarok ezzel utalni, hogy inkább válassz egy olyan keretrendszert, amiben szívesen dolgozol, mint egy olyat, ami 10-50%-kal gyorsabb, mint a másik. Elvégre 90%, hogy nem a kód futása miatt lesz lassú / gyors az alkalmazásod, hanem az I/O műveletek miatt.
58

Az I/O mindenhol I/O. A

Joó Ádám · 2011. Júl. 15. (P), 18.14
Az I/O mindenhol I/O. A különbség az, hogy rád kényszeríti-e a platform, hogy minden egyes lekérésnél I/O-t végezz.
38

Érdekes. Ha már „nem annyira

kuka · 2011. Júl. 14. (Cs), 20.07
Érdekes. Ha már „nem annyira a java vs PHP”, gyorsan kiegészítettem még kettővel. Nálam Java 0m0.089s, PHP 0m3.338s, Ruby 0m2.352s, Python 0m4.385s.

De még egy apróságra kíváncsi volnék: vajon melyik mennyi memóriát zabál munka közben. Van valakinek ötlete, hogy ezt Linux alatt mivel lehetne lemérni?

(Megjegyzés: a fenti mérési eredmény ellenére megmaradok Java-kerülőnek.)
33

Bonyolult üzleti logikát

phtamas · 2011. Júl. 14. (Cs), 19.35
Bonyolult üzleti logikát olykor macerás egy olyan nyelvben implementálni, amelyben a skalár typehinting hiánya és a - néhol nehezen követhető - implicit típuskonverziók miatt tetszőleges nemkonstans kifejezés értékét a csillagok állása határozza meg.
Nem állítom, hogy lehetetlen (én legalábbis nap mint nap próbálkozom vele), csak azt, hogy ha van választási lehetőség, akkor érdemes lehet mérlegelni.
35

Egyébként a Coldfusion az

H.Z. v2 · 2011. Júl. 14. (Cs), 19.37
Egyébként a Coldfusion az tiszta java vagy .jsp oldalakat jelent?
37

JSP

Poetro · 2011. Júl. 14. (Cs), 19.42
Leginkább a JSP-hez hasonlít, Java EE felett fut.
42

mysql_query, form builder

Práger Ádám · 2011. Júl. 14. (Cs), 22.11
Egy egyszerű MySql lekérdezés is már több osztályból, függvényből áll. Amit el nem tudok képzelni, hogy miért jobb ennél:

Amin teljesen kibuktam, hogy már egy formot is egy tucat függvénnyel állítanak elő. Senki se mondja azt, hogy ez vetekedhet egy HTML formmal, és sebességével !


Ne érdekeljen ennyire ez a sebesség téma. Egyrészt ha utána nézel, akkor rájössz, hogy egy jó ORM még gyorsabb is mint a sima mysql_query(tranzakciók miatt...ha magadtól is így írod a kódod, akkor én kérek elnézést). Másrészt nem fog egyik megrendelőd sem ezen szőrözni, akkora különbség nincs.

A Form builder meg a szükséges rossz. Ahogy már előttem is sokan írták az idő pénz, és rengeteg időt spórolsz vele.

Szerintem a Kohana jó választás kezdőként, a CodeIgniter nem az én ízlésem. Ha meg bátor vagy akkor Zend(bár lehet, hogy kohanával kezdenék, és mikor kijön a Zend2 akkor váltanék) vagy Symfony 2.
43

egy jó ORM még gyorsabb is

H.Z. v2 · 2011. Júl. 15. (P), 03.44
egy jó ORM még gyorsabb is mint a sima mysql_query(tranzakciók miatt...ha magadtól is így írod a kódod, akkor én kérek elnézést

Ezt részleteznéd? Hol függ össze a sebesség és a tranzakciók?
Milyen sebességre gondolsz? (Ha mySQL-ről beszélünk, akkor myIsam motor mellett milyen tranzakciókra?)
Egyébként eddigi olvasmányaim alapján arra a következtetésre jutottam, hogy ha objektum orientált környezetben dolgozol, akkor két választásod van:
- írsz saját ORM-t (max. nem hívod annak, de funkcionalitás tekintetében mégis az lesz)
- használsz egy már meglévőt.
44

Én ma már nem ajánlanám

Hidvégi Gábor · 2011. Júl. 15. (P), 08.33
Én ma már nem ajánlanám senkinek a MyISAM használatát. Komolyabb projekteknél nem kockáztatnék adatvesztést, kisebbeknél pedig szerintem úgysem jön elő a sebességbeli különbség.
45

Doctrine

Práger Ádám · 2011. Júl. 15. (P), 08.52
Itt egy doctrineos slide:

http://www.slideshare.net/jwage/doctrine-2-not-the-same-old-php-orm

47-54 ig van az ide vágó rész.
46

Attól kezdve, hogy a "mezei"

H.Z. v2 · 2011. Júl. 15. (P), 09.09
Attól kezdve, hogy a "mezei" mysql-nél nem használ parse-t(ja, ahhoz mysqli kellene, de a régi egyébként is lassan kikerül a támogatott driverek közül), nem tartom túlságosan hitelesnek az összehasonlítást.
Nem beszélve arról, vajon hányszor futtatták le ezt a tesztet? Mert ha egyszer, akkor ilyen időeltérés akármiből is következhet...
Közben olvasom tovább: ja hogy kötegelt feldolgozást csinál? Gyakorlott programozó nem követi el azt a hibát, hogy tömeges adatbevitelnél minden insertet külön tranzakcióba pakol...

Itt egyébként nem maga a tranzakció gyorsít, hanem az, hogy a hagyományos módszerrel végrehajtott SQL mellett (elvileg) lefut egy automatikus tranzakció indítás és egy commit a végén. E két műveletnek elég komoly erőforrás igénye lehet.


update: azért a linkelt blogból picit több kiderül.
http://www.doctrine-project.org/blog/transactions-and-performance
47

így van. De jellemzően aki

Práger Ádám · 2011. Júl. 15. (P), 09.11
így van. De jellemzően aki nem dolgozik keretrendszerekkel, az nem törődik ezzel. Ritka a kivétel...
48

Már úgy érted, a tömeges

H.Z. v2 · 2011. Júl. 15. (P), 09.13
Már úgy érted, a tömeges inzertek/update-ek csoportos tranzakcióba csomagolásával nem törődnek? Hát az elég szomorú...
49

Hétvégenként szoktam

Práger Ádám · 2011. Júl. 15. (P), 09.22
Hétvégenként szoktam beugrálni projektmelókba, ismerősöket kisegíteni, és nem egyszer volt már olyan, hogy egy majdnem kész oldalba kellett valami apróságot beleírnom. Elég gázos kódokat láttam, ebből merek arra következtetni, hogy ezzel sem törődnek, mint ahogy egy csomó más dologgal sem. Abban is biztos vagyok, ha visszanézném a saját, mondjuk úgy 2 évvel ez előtti kódomat ott sem lenne benne.
56

Fú hát én nemrég láttam egy

inf · 2011. Júl. 15. (P), 12.48
Fú hát én nemrég láttam egy olyan webshop kódját, ami naggyon durva volt :D struktúráltan írták meg az egészet, nem volt benne megjelenítés - egyéb dolgok elválasztása, sima mysql függvényeket használtak, és nem escapeltek semmit. Gyakorlatilag bármilyen támadást meg lehet valósítani a rendszer alatt. Fincsi volt :D Ja és front controller helyett egy jó nagy htaccess-t használtak, ami megcsinálja a route+dispatcher dolgát. Htaccess-ben gányoltam kicsit, hogy egyáltalán menjen az oldal, mert végtelen ciklusba került, amikor hozzáadtak még egy-két rule-t. A "fejlesztő" nem igazán értette, hogy hogy működik mindez :D
50

Nem egyértelmű első látásra,

Hidvégi Gábor · 2011. Júl. 15. (P), 09.36
Nem egyértelmű első látásra, hogy gyorsabb lesz összefűzni az INSERT-eket, mint N-szer meghívni a mysql_query()-t. Ráadásul a mysql_multi_query() használata egy hangyányival több erőfeszítést igényel, valamint a php.net-en elérhető példaprogram nem fut le 5.3 alatt, módosítani kell minimális mértékben.

Egyébként pedig az INSERT akkor a leggyorsabb, ha ilyen valahogy formában adod meg, egy darab lekérdezésben:
INSERT INTO ... VALUES (a, b, c), (a1, b1, c1);

Már csak azért sem egyértelmű a dolog, mert a fejlesztői szerveren általában nincs olyan terhelés, mint az élesen. Emellett az adatbázis is szinte üres, így minden művelet szinte teljes sebességgel fut le, és a sebességbeli problémák nem igazán jönnek elő.
51

Őszintén szólva nem értem,

H.Z. v2 · 2011. Júl. 15. (P), 09.56
Őszintén szólva nem értem, hogy ezt miért írtad.
Illetve, ha az autodidakta módszerekkel tanuló programozókról beszélsz, akkor OK, elfogadom.
De ilyesmit szinte alapfokon kell(ene) tanítani programozói szakon. Szerintem...
(mondom ezt úgy, hogy én középiskolában tanultam programozni, egy szovjet R20-ason, fogalmam sincs, a felsőoktatásban, programozás címszóval mit tanítanak)
52

Azért írtam, mert lehet, hogy

Hidvégi Gábor · 2011. Júl. 15. (P), 10.10
Azért írtam, mert lehet, hogy számodra egyértelmű, hogy egybe kell fűzni, de a kezdők számára nem. Ismerni kell a rendszerek működését (hogy például InnoDB alatt minden művelet külön tranzakcióba kerül), ahhoz pedig évek tapasztalata meg a dokumentációk átrágása kell. Elég megnézni pár fórumtémát és hozzászólást, hogy kiderüljön, eddig még sokan nem jutottak el.

Pont emiatt kezdeményeztem korábban, hogy a Weblaboron legyen valami tutorialgyűjtemény, ahol az ilyen dolgok példákkal illusztrálva le vannak írva.
53

jellemzően aki nem dolgozik

H.Z. v2 · 2011. Júl. 15. (P), 10.16
jellemzően aki nem dolgozik keretrendszerekkel, az nem törődik ezzel. Ritka a kivétel...


Én ezen akadtam el, ez nem a kezdőkről szól, hanem általában a programozókról, akik nem használnak keretrendszert. Sajnos láttam példát ilyesmire, de nem gondolnám, hogy ez általános lenne - vagy ha mégis, akkor nagyon felhígult ez a szakma is.

Az a tutorial gyűjtemény nekem is jól jönne néha. Egyre nehezebben találok megfelelő doksikat, oktató anyagokat :-(
Egyébként azért küzdök már fél éve a PHP hülyeségeivel, hogy összerakjak egy blogot, amin dokumentálom a programozással kapcsolatban megtanultakat. Ha ez kész, többé rá sem akarok nézni a PHP-re. Ehhez kell még néhány év. :-)
54

Valamilyen szinten szerintem

Hidvégi Gábor · 2011. Júl. 15. (P), 10.45
Valamilyen szinten szerintem mindenki használ keretrendszert, a legminimálisabb esetben egy függvénygyűjteményt, amit magának írt, hogy a gyakran használt funkciókat egy helyre gyűjtse. Hogy ezt OOP-vel vagy anélkül oldja meg, igazából szerintem egyéni ízlés kérdése, lehet mindkét módon jól és rosszul is. Úgy gondolom, hogy egy átlag website-nál nem jön elő sebességbeli probléma, bármilyen rosszul programoz is az illető, mert olyan gyorsak a mai szerverek.