Emlékszem, mikor még a PHP 4 volt számomra az egyetlen verzió. Majd igen késve belekóstoltam a PHP 5-be és tetszett, amit láttam. Azóta is folyamatosan fejlődött. Kapott új függvényeket is, de mégsem volt olyan látványos a változás. Hozzáteszem, a unicode változónevek használata sem jelentéktelen, ami már 5.3 előtt is létezett, de a valódi haszna mégis megkérdőjelezhető. Majd az 5.3 -as verzióban többek között bevezették a névtereket. Persze nem nagyon volt még akkor olyan szerver, ahol ez a verzió futott volna. És mivel névterek nélkül is jól megvoltam addig, ezt a funkciót inkább nem is használtam. De az idő nem állt meg és elértünk az 5.2-es széria támogatottságának végéig. Amikor már mindenkit az 5.3-ra való átállásra ösztönöznek a PHP nyelv fejlesztői. Egyelőre még mindig több szerveren csak 5.2 van. Többek között a rimelek.hu szolgáltatóján is. Tervezik viszont ők is, hogy bevezetnek 5.3-as szervert is, amire kérésre át lehet majd kerülni. Van ingyenes szolgáltató, ami már korábban váltott. Ilyen a Freeweb.hu is. Lehet több is van. Nem néztem utána. Már 5.3.8 -nál tart ez a széria. És bár korábban sokan hallhattak a 6-os verzióról, a következő az 5.4 lesz.
A PHP 5.4 ismét olyan újításokat vezet be, ami miatt megint lehet egy kicsit dicsérni a nyelvet. De hogyan jutottunk ide?
PHP 1
Az első PHP verzió. Rasmus Lerdorf-tól. Itt még nem az volt a cél, hogy egy széles körben használt szkriptnyelv legyen. Akik vettek könyvet PHP tanuláshoz, azok olvashattak róla, hogy Rasmus ezt egy könnyítésnek szánta csak személyes weboldalakhoz. Volt alkalmam belenézni a forráskódjába. A maiakhoz képest érthető módon sokkal olvashatóbb forrása van. Mindössze 6 fejlécfájlból, 8 C forrásfájlból, 2 szövegfájlból és egy Makefile-ból állt. Olyan függvényei voltak a C forrásnak, mint például:
* ShowEmailPasswordForm
*
* Prompt user for both an email address and a password
*/
void ShowEmailPasswordForm(char *cmd, char *filename) {
puts("<html><head><title>Email Address and Password Required</title></head>");
puts("<body><center><h1>Email and Password Required</h1></center>");
puts("This document is protected by a password. You must know this");
puts("password in order to continue. You are also asked to enter your");
puts("email address. If either of these fields are not filled out, you");
puts("will not be granted access.<p>");
printf("<form action=\"%s?%s\" method=\"POST\">\n",cmd,filename);
printf("<input type=\"hidden\" name=\"http_referer\" value=\"%s\">\n",referer);
printf("<center><tt>Email Address</tt><br><input type=\"text\" name=\"email\" size=40 value=\"%s\"></center><p>\n",email_addr);
puts("<center><tt>Password</tt><br><input type=\"password\" name=\"password\"></center><p>");
puts("<center><input type=\"submit\" value=\" SEND \"></center><hr>");
printf("<font size=-1><i><a href=\"%s\">PHP Tools</a> Copyright © 1995 Rasmus Lerdorf</i></font><br>\n",PHPURL);
puts("</body></html>");
}
Ezt nagyon magyarázni sem kell. Ez volt a start. És nem állt meg.
PHP 2
A forrásfájlok száma és így a funkciók is bővültek. Már lehet látni reguláris kifejezéseket, képkezelést, fájlkezelést. Van példa benne email küldésre is, de még nem a mail függvénnyel, hanem a rendszer sendmail programját használva. Volt benne adatbázis kezelés. Főként mSQL-t látni benne. Amit egy idő után felváltott a mySQL. A letölthető csomagban egyébként található a példafájlokon kívül egy dokumentáció is. Itt még bőven elég volt egyetlen html fájlban összegyűjteni a lényeget.
PHP 3
Külön windows specifikus megoldásokkal gyarapodott. Dinamikus könyvtárbetöltési lehetőséggel, amire a dl() függvény szolgált. Itt már látni osztályokat is:
var $a;
var $b;
cfunction display() {
echo "This is class foo\n";
echo "a = ".$this->a."\n";
echo "b = ".$this->b."\n";
}
cfunction mul() {
return $this->a*$this->b;
}
};
class bar extends foo {
var $c;
cfunction display() { /* alternative display function for class bar */
echo "This is class bar\n";
echo "a = ".$this->a."\n";
echo "b = ".$this->b."\n";
echo "c = ".$this->c."\n";
}
};
A cfunction kulcsszó php4-ig létezett csak.
Aki szeretné megnézni az első 3 verziót, letöltheti a forráskódokat a museum.php.net oldalról.
PHP 4
Az első 3 verzió olyan régi, hogy az már történelem. És nem is volt alkalmam programozni bennük. A 4-es viszont még sokak emlékeiben élhet. Az volt az első verzió, amivel dolgoztam. Az első könyv, amiből tanultam, még a 4.2 telepítését írta le. Akkoriban több könyvben is hibás példákat lehetett olvasni, mert adott szerverbeállításoknál azok a hibaüzenetek nem jelentek meg. Gondolok itt a tömbindexek idézőjelezésének elhagyására és űrlap használatakor annak ellenőrzésére, hogy az űrlap el lett-e küldve egyáltalán. Így aztán hosszú ideig lehetett olyan bejegyzésekkel találkozni fórumon, hogy „De hát a könyvben így írták” Persze az, hogy ez már ritkább, nem a PHP fejlődésének köszönhető, hanem inkább a könyvek szerzőinek.
Osztályok, objektumok
Az osztályok még mindig igen kezdetlegesek voltak. Akkoriban mégis nagy szó volt számomra, hogy már ismerem ezt a „modern” technológiát. Közel sem tudtam még azonban, hogy mi is a valódi jelentősége az objektumorientált programozásnak.
Osztály php 4-ben
{
var $prop;
function A($prop)
{ //konstruktor
$this->prop = $prop;
}
function method()
{
return $this->prop;
}
}
$a = new A(54);
echo $a->prop;
Nem volt viszont lehetőség adattagok elrejtésére. A konstruktor az osztálynévvel megegyező nevű metódus volt. Ráadásul akkor még az objektumok nem referencia szerint adódtak át. Vagyis ha nem tettünk & jelet az objektum elé, mikor átadtuk egy másik változónak, vagy egy metódusnak, függvénynek, akkor az objektumról másolat készült és azzal dolgozhattunk tovább.
PHP 5.0 - 5.2
Ennek a verziónak legnagyobb vívmánya az OO lehetőségek továbbfejlesztése volt. Az objektumorientált szemlélet főbb alapelveit már megvalósította, így egyre könnyebb lett bizonyos problémák megoldása és elmondhattuk, hogy PHP-ben igenis lehet objektumorientáltan is programozni. Ez kezdetben még a fizetős tárhelytulajdonosok kiváltsága volt. Majd megjelentek ingyenes tárhelyek is az 5-ös verzióval. Érdekesség, hogy még mindig vannak olyan tárhelyek, mint például az uw.hu, ahol még a muzeális PHP 4.4.7 -es verzió van. De mik is lettek az újdonságok OO területen?
Láthatóság
A 4-es verziónál írt példámnál a tulajdonság előtt a var kulcsszó áll. A metódusok előtt pedig semmi. Bármelyik tulajdonság és metódus bárhonnan elérhető, módosítható volt. Erre a php 5 bevezetett 3 kulcsszót. public, protected, private.
A public gyakorlatilag a var álneve. De mégis többet mond a tulajdonság jellegéről.
A protected-del elérhető lett, hogy egy metódus, vagy tulajdonság ne legyen elérhető máshonnan, csak az őt tartalmazó osztály metódusaiból, vagy a belőle leszármaztatott osztályokban. Lényeges, hogy itt osztályokról beszélünk és nem objektumokról. Ugyanis egy adott osztály szabadon elérheti egy másik példány bármely védett metódusát is, ha az saját magában, vagy egy szülőjében van definiálva.
{
protected function prot() {
return 'Védett';
}
}
class B extends A
{
}
class C extends A
{
public function test()
{
$b = new B();
return $b->prot();
}
}
$c = new C();
echo $c->test(); //Védett
A private-tel jelölt metódusokat pedig csak az őt tartalmazó osztály érheti el. Szintén érvényes a fenti kijelentésem, mi szerint osztályokról beszélhetünk továbbra is, nem objektumokról.
Type hinting
Erősen típusos nyelvekben a változók, tulajdonságok, metódusok előtt meg kell adni a típust is. Legyen az primitív, vagy osztály. PHP 5-ben csak lehetőség és csak függvényekben, metódusokban ( vagy catch blokkban. Erről később. ) a paraméterek előtt. Valamint csak array és osztálynév, interfésznév állhat típusként.
{
public $name = 'Név';
}
function showName(Person $person)
{
echo '<b>'.$person->name.'</b>';
}
showName(new Person()); //<b>Név</b>
Absztrakt osztály és metódus
A abstract kulcsszó lehetővé tette, hogy olyan osztályokat definiáljunk, amikből példány nem hozható létre. Kizárólag az ősosztály szerepét töltik be az osztályhierarchiában. Illetve olyan metódusokat, amiknek nem adjuk meg a törzsét, csak a fejrészét. Ezeket a metódusokat aztán kötelező kifejteni a gyermekosztályban. Következik ebből, hogy absztrakt, vagy absztrakt metódust tartalmazó osztály nem példányosítható. Annak statikus, kifejtett metódusai viszont használhatók.
{
abstract function test();
public static function x()
{
echo 'ize';
}
}
D::x(); //ize
Interfészek
Az interfészekkel egy olyan felületet lehet meghatározni, amivel az adott osztály kommunikálhat a külvilággal. Tehát egy olyan metóduslista gyakorlatilag, aminek minden metódusa publikus. És az őt megvalósító osztály is köteles ezeket publikusnak definiálni. Bizonyos szempontból tehát hasonló az absztrakt osztályhoz, de itt csak metódusok fejrésze adható meg és azok is csak publikusan. Mindkettő a típus szerepét is betölti, így a type hintinggel együtt remekül használható. Az adott objektummal dolgozó metódus pedig biztos lehet benne, hogy mindig rendelkezésére állnak majd a kellő metódusok.
interface IProgrammer
{
public function createProgram();
}
class PHPProgrammer implements IProgrammer
{
public function createProgram()
{
return '<?php echo "Program"; ?>';
}
}
class JavaProgrammer implements IProgrammer
{
public function createProgram()
{
return '
class Test {
public static void main(String[] args) {
System.out.println("Hello Batman!");
}
}';
}
}
class Employer
{
public function testAProgrammer(IProgrammer $programmer)
{
return ($this->programIsWorking($programmer->createProgram()));
}
private function programIsWorking($sourcecode)
{
//Minden programot elfogadó munkáltató
return true;
}
}
$phpProgrammer = new PHPProgrammer();
$javaProgrammer = new JavaProgrammer();
$employer = new Employer();
if($employer->testAProgrammer($phpProgrammer)) {
echo 'Felvesszük!';
} else {
echo 'Nem vesszük fel';
}
if($employer->testAProgrammer($javaProgrammer)) {
echo 'Felvesszük!';
} else {
echo 'Nem vesszük fel!';
}
Ezek a programozók természetesen nem csak programozni tudnak, de ezt a képességüket kell tudnia leellenőrizni a munkáltatónak, így ennek mindenképpen létezni kell. Ha elhagyom a createProgram metódust bármelyik programozónál, akkor értelmezés közben hibaüzenettel leáll a program.
Fatal error: Class JavaProgrammer contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (IProgrammer::createProgram) in /home/***/index.php on line X
Ha pedig nem is implementálom a programozó osztályában az interfészt, akkor a munkáltató nem fogadja el programozónak és meg sem próbálja letesztelni.
Catchable fatal error: Argument 1 passed to Employer::testAProgrammer() must implement interface IProgrammer, instance of JavaProgrammer given, called in /home/***/index.php on line X and defined in /home/***/index.php on line X
Felülírás megtiltása
A final kulcsszó is igen hasznos lehet, ha azt akarjuk, hogy egy ezzel jelzett metódust további leszármazott osztályokban ne lehessen felülírni. Biztosítva ezzel, hogy annak funkcióját ne lehessen megváltoztatni. Osztály elé írva pedig az adott osztályból még örököltetni sem lehet további osztályokat.
{
final public function fin()
{
return 'Na, te engem csak ne írj felül!';
}
public function test()
{
return $this->fin();
}
}
class B extends A
{
public function fin() //Fatal error: Cannot override final method A::fin() in /home/***/index.php on line X
{
return 'Jól kitolok az A osztállyal. Hiába mondta, hogy "'.parent::fin().'"';
}
}
$b = new B();
echo $b->test();
class D extends C { } //Fatal error: Class D may not inherit from final class (C) in /home/***/index.php on line X
Mágikus metódusok
Egy sor olyan metódus létezik, ami valamilyen eseménynek hatására fut le. Nem közvetlen hívással. Ezek a __construct(), __destruct(), __call(), __get(), __set(), __isset(), __unset(), __sleep(), __wakeup(), __toString(), __set_state(), __clone() metódusok. Mindet nem is magyaráznám meg részletesen. A konstruktorról már írtam. Itt külön neve van, de még a régi módszer is használható. A __destruct() pedig akkor fut le, amikor az objektum megszűnik. A __get(), __set(), __call() metódusok segítségével dinamikusan, futásidőben tehetünk elérhetővé olyan tulajdonságokat, metódusokat, amelyek nem is léteznek. Ami remek lehetőség olyan modell osztályok írására, amik egy adatbázis tábla mezői alapján kapnak tulajdonságokat. Az __isset(), __unset() metódusok a hasonló nevű nyelvi konstrukciókkal (isset, unset) függnek össze. Mivel a nem létező tulajdonságokra másképp az isset hamisat adna, az unset pedig nem is törölne. A __sleep() és __wakeup() megint érdekesek, bár élesben még soha nem kellett használnom. Előbbit a serialize() függvény idézi elő, utóbbit pedig az unserialize(). Normál esetben, ha egy objektumot sorosítunk, minden állapota megőrződik változatlanul. Ha viszont tartalmazza az osztály a __sleep() metódust, akkor ez a metódus döntheti el, mely állapotokat kell megjegyezni „elalvás előtt”. Azon tulajdonságainak nevét egy tömbben kell visszaadnia, amit nem akar elfelejteni. Minden más visszaáll alapra. Majd ébredéskor el lehet dönteni, mi legyen ezekkel az állapotokkal. Mutatok egy életszerű helyzetre egy forráskódot.
{
private $name;
private $hungry = false;
private $sleepy = false;
public function __construct($name)
{
$this->name = $name;
}
public function eat()
{
echo 'Eszem<br />';
$this->hungry = false;
}
public function work()
{
echo 'Dolgozom<br />';
$this->hungry = true;
$this->sleepy = true;
}
public function howAreYou()
{
echo '<span style="color: red;">Én, '.$this->name.',<br />',
($this->hungry) ? 'éhes vagyok' : 'nem vagyok éhes','<br />',
($this->sleepy) ? 'álmos vagyok' : 'nem vagyok álmos', '<br /></span>';
}
public function __sleep()
{
echo 'Alszom<br />';
return array('name');
}
public function __wakeup()
{
echo 'Felkelek és nyújtózom<br />';
$this->hungry = true;
}
}
$person = new Person('Ákos');
$person->howAreYou();
$person->work();
$person->howAreYou();
$person->eat();
$person->howAreYou();
$person = serialize($person);
$person = unserialize($person);
$person->howAreYou();
Itt a személy alapból nem is éhes és nem is álmos. Teszi a napi, szokott dolgait, majd valamilyen állapotba kerül. Elálmosodik és lefekszik aludni. Mint ahogy az lenni szokott, az ember alvás után is megőrzi a nevét. A többi változhat. Ezért nem is kell megjegyezni. Ébredéskor általában megéhezik.
Az eredmény:
Én, Ákos,
nem vagyok éhes
nem vagyok álmos
Dolgozom
Én, Ákos,
éhes vagyok
álmos vagyok
Eszem
Én, Ákos,
nem vagyok éhes
álmos vagyok
Alszom
Felkelek és nyújtózom
Én, Ákos,
éhes vagyok
nem vagyok álmos
A __toString() metódus pedig 5.2 előtt akkor futott le, amikor echo-val vagy print-tel a képernyőre lett küldve az objektum. És így annak általunk meghatározott string reprezentációját lehetett kiírni. 5.2 óta pedig bármilyen implicit vagy explicit string konverzió hatására lefut. Kibővítve tehát a Person osztályt:
{
return $this->name;
}
Már a személy nevének kiírása ennyiből áll: print $person;
Klónozás
Az előző pontból kimaradt a __clone() metódus magyarázata. A PHP 4-es verziójában, mint említettem, minden objektum érték szerint, azaz másolatként lett átadva újabb változóknak. Ez viszont az 5-ös verzióban végre megváltozott. És az alapértelmezett a referencia szerinti átadás lett. Így viszont ha épp az objektum másolatára lenne szükség, már nem elég a $person2 = $person;, hanem kell a clone kulcsszó is. $person2 = clone $person; Így a két változó már nem ugyanarra az objektumra mutat. De mi van akkor, ha nem teljesen tökéletes másolatot szeretnénk, hanem csak egy nagyban egyezőt? Ilyenkor kell a __clone() metódus, ahol még változtatni lehet a tulajdonságokon.
public function __clone()
{
$this->name .= ' klónja';
}
//...
$person2->work();
$person2->howAreYou();
//Dolgozom
//Én, Ákos klónja,
//éhes vagyok
//álmos vagyok
Egyelőre túl gyakran klónoznom sem kellett, de ettől függetlenül a lehetőséget nagyon jónak tartom. És úgy egyáltalán a PHP 5 összes újdonságát, ami az OOP-t illeti. Úgy, ahogy a következő pontban leírtakat is.
Kivételek
Már mire bevezették a kivételeket, programoztam C# -ban. Onnan ismertem meg a kivételkezelés alapjait. És ezért ami furcsa volt elsőre PHP-ban, hogy nincsenek olyan kivételek, amiket a rendszer maga dobna. Helyette mindig a különböző szintű hibaüzenetek jelentek meg. Például egy nullával való osztásnál C# -ban kivétel keletkezik, amit kezelni lehet. Míg PHP-ben magamnak kellene minden osztás művelet előtt vizsgálnom az osztó értékét. És szükség esetén kivételt dobni. Valahogy így:
function div($a, $b)
{
if ($b == 0) {
throw new DivideByZeroException('Nullával nem lehet osztani!');
}
return $a / $b;
}
try {
echo div(10, 0);
} catch(DivideByZeroException $e ) {
echo $e->getTraceAsString();
}
Erről hosszan lehetne írni. Vannak, akik megkérdőjelezik a hasznukat. Ők főleg a kevésbé tapasztaltabbak. Az a helyzet, hogy egy nullával való osztásnál kevésbé látszik a jelentősége. De egy összetettebb alkalmazásnál igen nagy előny, hogy egy hibát ( kivételt ) a program több szintjén el lehet kapni és kezelni. Valamint a hiba típusától függően, többszintű kivételhierarchia esetén általánosabb és speciálisabb „választ” is lehet adni rá. Bizonyos nyelvekben létezik a try és catch blokkon kívül egy finally is. Ezért vannak, akik azt hiszik, hogy PHP-ban is így van. De nincs. PHP-ban nincs finally blokk.
Automatikus osztálybetöltés
PHP 4-ben minden fájlt be kellett hívni a programozónak a forrásban, mielőtt a benne levő osztályt használta volna. Majd, ha meggondolta magát és más osztályra lett volna szüksége, akkor a fájl include-okat is át kellett írni. Ez ugye valljuk be, igen kényelmetlen. És ráadásul attól, hogy egy programban szükség lehet egy osztályra, még nem biztos, hogy szükség is lesz. Az a lehetőség persze még adott volt, hogy az osztályok betöltésére saját betöltő megoldást írunk és a hozzá tartozó fájlokat is az a metódus vagy függvény illeszti be, ha szükséges. De erre jött a megváltás az __autoload() függvény formájában. Ami megfelelő, következetes fájlnevek és könyvtárszerkezet mellett automatikusan betöltheti azokat a fájlokat, amikhez tartozó osztályokat valahol megpróbáljuk használni. Ez azért is jó, mert rákényszeríti a programozót arra, hogy olyan osztály- és fájlneveket találjon ki, amivel ez megvalósítható. Ezzel a program struktúrája is átláthatóbb lesz.
{
require_once dirname(__FILE__).'/'.str_replace('_','/',$class).'.php';
}
$object = new Path_Classname();
//Path/Classname.php
Ez persze csak a legegyszerűbb és nem a legjobb megoldás. Így az osztályok linux szervereken érzékenyek lesznek a kis és nagybetűk különbségére az osztálynévben. De ezen egy strtolower függvény segít. Ha minden fájl és mappa megállapodás szerint kisbetűs. Viszont kétséget kizáróan hasznos.
SPL
A PHP híres arról, hogy rengeteg beépített függvénye van. Habár kap olyan kritikákat, hogy azok nem következetes elnevezésűek és paraméterezésűek. Ebben van is igazság. De túl lehet lépni rajta. Az 5-ös verzióban pedig bevezették az SPL-t. Azaz a Standard PHP Library-t. Olyan osztályok, interfészek gyűjteménye, amivel speciális adatstruktúrákat vagy bejárási módszereket valósíthatunk meg. És nem utolsósorban előre definiált kivételosztályokat tartalmaz. PHP 5.2 -ben még kikapcsolható volt a használata.
SPL-hez kapcsolódóan van még egy említésre méltó megoldás. Ez pedig az SPL Types. Type Hinting-nél említettem, hogy a PHP gyengén típusos nyelv. És a type hinting segítségével sem lehet az egyszerű típusokra korlátozni egy változó értékét. Ezzel a kiegészítéssel viszont már ezt is lehet. Egy rövid példa:
$int = 54;
$int = 'szöveg vagyok';
echo $int;
Ez például a harmadik sorra kivételt dobna. Mert nem csak azt kényszeríti ki, hogy egy metódusban ne lehessen átadni más típust, hanem azt is hogy egyáltalán ne kaphasson más típusú értéket, ha egyszer már SPLint volt. Ennek főleg ez a jelentősége, hiszen egy osztályt, aminek csak konstruktora van és egy értéket tárol, mi is bármikor meg tudnánk írni.
Próbáltam létrehozni az SplType -ból örökölve új típusokat. De ez nem sikerült. Ha valaki összehozza, ossza meg velem is. :)
Reflection osztályok
Zárásként úgy gondoltam, ezt is megemlítem ebben a verzióban. Mert nagyon sokszor hasznos lehet. Különféle Reflection osztályok vannak PHP-ban. Ezekkel futásidőben lehet elemezni egy osztályt vagy objektumot.
Még hosszan sorolhatnám valószínűleg a hasznos eszközöket, de valahol meg kell húznom a határt. Ha csak ennyit hallanék a PHP-ról, már az is felkeltené az érdeklődésemet. És még nincs vége.
PHP 5.3
Néhány függvény „deprecated” jelzőt kapott és természetesen új függvények is megjelentek. Innentől kezdve az SPL már nem volt kikapcsolható. És újabb ötletekkel is előállt, amik megkönnyítik a kódolást.
Névterek
A névterek bevezetését jó ötletnek tartottam. Bár azon meglepődtem, hogy azok elválasztására az egyébként escapelésre használt „\” jelet szavazták meg. De hát ez van, ezt kell szeretni. És szerintem van is rá okunk. Mert mi volt régen? Tegyük fel, volt két fejlesztő. Az egyik létrehozott egy System osztályt a webalkalmazásnak. De szerette volna használni egy másik fejlesztő vendégkönyv szkriptjét, aminek szintén volt System osztálya. Vagy átnevezte a vendégkönyv osztályát és minden ráhivatkozást is ennek megfelelően, vagy lemondott a vendégkönyvről. Ha okos volt a vendégkönyv fejlesztője, akkor egy GuestBook_System osztályt hozott létre. Igen ám, de így minden alkalommal ki kell írni az egész osztálynevet. És mivel minden programozó hivatásától fogva --, de egészséges értelemben -- lusta, ezt nem szeretjük.
5.3 előtt
class GuestBook_System { }
5.3 óta
class System {}
}
namespace GuestBook {
class System { }
}
Itt azt tudni kell, hogy az első névtér blokk a globális névtér. A gyökér. Ezen kívül nem kötelező blokkokként létrehozni a névtereket. Lehet akár egy fájl egész tartalma egy névtér alá tartozó. ilyenkor elég a fájl elején, de tényleg a legelején ennyi:
namespace GuestBook;
Lényeges, hogy egy fájlban nem lehet vegyesen használni a két módszert. Vagy a fájl elején van egy névtér definíció, ami után levő tartalom a következő definícióig adott névtérhez tartozik, vagy minden névtér blokként van megadva.
Az előző megjegyzésből adódik, hogy a nem blokkos megoldást használva gyökér névtérben nem definiálhatunk már semmit.
Itt azért még mindig felvetődik a kérdés, mi van, ha több GuestBook névtér van. Mert hát miért ne nevezhette volna el két fejlesztő ugyanúgy a vendégkönyve névterét. Főleg, ha ilyen triviális név. A megoldás, hogy a fejlesztő, vagy fejlesztőcsapat saját névteret definiál, és minden fejlesztését abba teszi. Például ha rólam lenne szó, akkor:
namespace rimelek\GuestBook { }
Ezzel lenne egy rimelek névterem, és azon belül a GuestBook névtér. Így a névütközések elkerülhetők. Egy adott névtéren belül, az ugyanabba a névtérbe tartozó osztályok és további névterek közvetlenül elérhetők anélkül, hogy a teljes névtér útvonalat kiírnánk. Olyan ez, mint html-ben a base tag. A fájl elején, vagy a blokkban definiált névtér megadja a default útvonalat. Ha pedig a gyökértől kell hivatkozni egy alsóbb névtérre, akkor „\” jellel kezdve a gyökér névtértől lehet hivatkozni az adott elemre.
Egy másik hasznos dolog, a use kulcsszó. Ennek php-ben több jelentősége is van. Névterek szempontjából az útvonalak egyszerűbb megadásában rejlik.
//vagy
use \ez\egy\nevter\utvonal;
$object = new \utvonal\Osztaly();
//vagy
use \ez\egy\nevter\utvonal\Osztaly;
$object = new Osztaly();
Na most ezzel így a névütközések elkerülésének látszólag lőttek, ha van egy globális Osztaly nevű osztály is. De itt jön képbe a másik nagyszerű lehetőség. A névterek és osztályok átnevezése. Ami pedig már önmagában megoldhatná a névütközéseket, ha a abból a megoldásból indulunk ki, amikor a fejlesztő a vendégkönyv System osztályát átnevezi. Mert itt nem kell mindenhol átírni a hivatkozásokat.
$object = new AtnevezettOsztaly();
//vagy
use \ez\egy\nevter\utvonal as AtnevezettUtvonal;
$object = new AtnevezettUtvonal\Osztaly();
Fontos, hogy az átnevezendő elemet teljes névtér meghatározással kell megadni. Akkor is, ha az az aktuális névtérben szerepel. Egyéb esetben a gyökér névtérben keresi az osztályt vagy névteret a program.
Függvények átnevezése nem lehetséges, de egy saját névtérben használhatunk ugyanolyan nevű függvényt, mint ami a gyökér névtérben létezik.
Végül pedig csak említés szinten írok a konstansokról. Ugyanis 5.3-ban a névterekhez tartozhatnak ugyanúgy const kulcsszóval definiált konstansok, mint osztályokon belül.
Nekem ugyan hiányzik az egymásba ágyazhatóság, amivel strukturáltabb formában lehetne a névtér definíciókat elhelyezni, de ettől függetlenül is egy olyan lehetőséget kaptunk, amit egyszerűen bűn nem alkalmazni. Illetve korábban írtam az __autoload függvényről, ami a névterek használatával kicsit módosulhat. Ugyanis az osztálynévbe ilyenkor beletartozik a névtere is. Azaz az aláhúzás karakterek „/” jelre cserélése helyett vagy mellett lehet a „\” jeleket cserélni. Ennek megfelelően strukturálva a fájlokat a névterek használatával, hasonlóan áttekinthető forrást írhatunk, mint például javaban, ahol a névterekhez hasonló package-ek léteznek.
Mágikus metódusok
Az 5.2-es verziónál 2 mágikus metódust kihagytam, ami csak 5.3 óta létezik.
A egyik a __callStatic(). A __call() metódus statikus párja. Ami igen hasznos, hiszen ha egy objektumnak lehet futásidőben definiált metódusa, egy osztálynak miért ne lehetne statikus formában? Mutatok majd példát is rá, hogy mikor érdekes.
A másik pedig az __invoke(), ami egy objektumot tesz függvénykényt hívhatóvá. Hogy mi a jelentősége? Többféleképpen is fel lehet használni. De például a konstruktor tartalmát ebbe másolva, és a konstruktorban csak meghívva megoldható, hogy az objektum konstruktorban átadott adatait bármikor átértékeljük. De használható akár arra is, hogy az objektumot megfeleltessük egy értéknek. Ami a __toString() -ben visszaadható értékhez képest nem csak string lehet. És most jöjjön egy példa arra, mit lehet alkotni ezekkel a metódusokkal. A példa az egyszerűbb matematikai műveleteket valósítja meg, statikus és példányszintű megvalósítást is nyújt egyszerre.
{
private $value;
private static $operations = array(
'add' => '+',
'sub' => '-',
'mul' => '*',
'div' => '/',
'mod' => '%'
);
public function __construct($number)
{
$this->value = $number;
}
private static function operation($a, $b, $method)
{
return eval(sprintf('return %f %s %f;',$a, self::$operations[$method], $b));
}
public function __call($method, $args)
{
array_unshift($args, $this());
$this(self::__callStatic($method, $args));
return $this;
}
public static function __callStatic($method, $args)
{
$method = strtolower($method);
if (!isset(self::$operations[$method])) {
throw new BadMethodCallException('Nincs '.$method.' nevű művelet!');
}
$args[] = $method;
return call_user_func_array(array(__CLASS__, 'operation'), $args);
}
public function __invoke($value=null)
{
if (!is_null($value)) {
$this->value = $value;
}
return $this->value;
}
public function __toString() {
return (string)$this->value;
}
}
echo Math::add(5, 8)."<br />";
$math = new Math(56);
echo $math->add(5)."<br />";
echo $math->sub(12)."<br />";
echo $math->add(4)->sub(2)->div(2)->mul(3)->sub(0.5)->mod(3);
Névtelen függvények
A névtelen függvények szintén ismerősek lehetnek JavaScript-ből sokaknak. És PHP-ben is létezett egy lehetőség már rá korábban, de igen csúnya megoldás volt az. A paraméterek listáját és a forráskódot is stringként kellet átadni. egy függvénynek, ami elkészítette a névtelen függvényt és így az változóba tölthető lett. Semmi más lehetőséget nem adott. És ezzel a megoldással a szerkesztésidejű szintaktikaelemzésről is le kellett mondanunk a forráskódszínezéssel együtt. Majd jött az 5.3 és beépítette a szintaktikájába a névtelen függvény lehetőségét. Ami ráadásul egy objektumot hozott létre, nem is csak függvényt. Bár függvényszerűen volt hívható, ami az előző pontban említett __invoke() mágikus metódusnak köszönhető..
5.3 előtt
echo $func(7, 9);
5.3 óta
return $a + $b;
};
echo $func(1, 6);
Lényeges, hogy a függvény záró kapcsos zárójele után pontosvessző kell!
Mivel ez egy objektum, ami a Closure osztály példánya, így a type hinting-gel is együtt használható. Azaz ki lehet kötni, hogy kizárólag névtelen függvényeket lehessen átadni.
{
echo $func(8, 9);
}
És ismét megjelenik a use kulcsszó. Ismét JavaScript-re hivatkoznék. Abban ugyanis a névtelen függvényben elérhetők a külső változók is. Itt viszont nem. Ha mégis szeretnénk elérni őket, két lehetőség van. Vagy a global kulcsszóval beemeljük a változókat, ami nem javasolt és olyankor a függvényben az eredeti változó is megváltoztatható, vagy használjuk a szuper use kulcsszót.
$y = 15;
$z = 26;
$f = function($x) use ($y, &$z) {
var_dump($x++, $y++, $z++);
};
$f(8);
$f(9);
Első ránézésre felfoghatnánk úgy is, mint két további paraméterét a függvénynek. De a trükk abban van, hogy a függvényt akárhol meghívhatom, ahol a use-ban megadott két paraméter nem létezik, ha a függvénydefiníciónál létezett.
Késői statikus kötés
Ennek a lényege, hogy míg egy objektumnál az öröklési lánc bármely osztályában hivatkozhatunk a $this változóval bármely osztályban definiált metódusra, tulajdonságra, úgy azt nem tehetjük meg statikusan. Vagyis nem tehettük meg 5.3 előtt. Az osztályokra a self és parent kulcsszavakkal lehetett hivatkozni. Az első az aktuális osztályra vonatkozik, míg a második a szülőre. De egyik sem hivatkozik a majdan esetleg valamelyik gyerekben deklarált, avagy felülírt metódusra. 5.3 -ban erre jó a static kulcsszó. Aminek egyéb funkcióit már ismerjük. Ezzel együtt megjelenik a get_called_function() nevű metódus is, ami a static által hivatkozott osztály nevét adja vissza. Na most ennek haszna a következő. Korábban egy egyke osztály így nézett ki:
{
private static $instance = null;
private function __construct() {
}
public static function instance()
{
if (is_null(self::$instance))
{
self::$instance = new self();
}
return self::$instance;
}
}
Bár ezt már régen is lehetett php-ben sokkal rövidebben:
{
private function __construct() {
}
public static function instance()
{
static $instance;
if (!isset($instance)) {
$instance = new self();
}
return $instance;
}
}
De ezt az összes osztályban, ami singleton, meg kellett írni. Ezen lehetett segíteni ugyan a következő módon:
{
final private function __construct() {
}
public static function instance()
{
if (is_null(self::$instance))
{
self::$instance = new self();
}
return self::$instance;
}
}
class A extends Singleton
{
public static function instance() {
return parent::instance(__CLASS__);
}
public function tesztB()
{
return __METHOD__;
}
}
De így is a programozóra van bízva, hogy az instance metódust felülírja. Ezen segít a static kulcsszó és a get_called_class() metódus:
{
final protected function __construct() {
}
public static function instance()
{
static $instance;
$class = get_called_class();
if (!isset($instance[$class])) {
$instance[$class] = new static();
}
return $instance[$class];
}
}
class A extends Singleton
{
public function tesztA()
{
return __METHOD__;
}
}
Heredoc / Nowdoc
A heredoc szintaxis már korábbi találmány. Arra való, hogy egy nagyobb stringet, amiben ráadásul idézőjelek is lehetnek, ne kelljen idézőjelbe tenni és a belső idézőjeleket escapelni, hanem egy választott azonosító segítségével ezt ki lehessen kerülni.
$text = <<<T
Ez egy szöveg $valtozoval.
T;
//Ez egy szöveg 10
A nyitó és záró kulcsszó megegyezik. Valamint a záró kulcsszó mindig a sor elején van. Előtte nem lehet space sem!
Mint látható, ez olyan, mintha normál idézőjelbe tettem volna a szöveget. És így a változók is kiértékelődnek benne. De ha nem ez a cél, akkor segít a nowdoc szintaxis. Ami annyiban különbözik, hogy a nyitó kulcsszó körül ugyanannak az idézőjelpárnak kell lennie, mint amibe az érintett stringet szeretnénk tenni.
$text = <<<'T'
Ez egy szöveg $valtozoval.
T;
//Ez egy szöveg $valtozoval
PHP Archívum
Na ez egy érdekes dolog megint. Mert gyakorlatilag a ZipArchive osztályon alapul, de a célja, hogy egy alkalmazást be lehessen csomagolni egy archívumba, ami egyben futtatható is. A Phar extension-nek igen sok lehetősége van, de én csak egy rövid ( tényleg ) példát írok.
try {
$phar = new Phar('myphar.phar');
$phar['index.php'] = '<?php echo "Ez a főoldal"; ?>';
$phar['other.php'] = '<?php echo "Ez nem a főoldal"; ?>';
$phar->setStub('<?php
Phar::webPhar();
__HALT_COMPILER(); ?>');
} catch (Exception $e) {
echo $e->getMessage(),"\n";
echo $e->getTraceAsString();
}
Ezzel létrehoz egy myphar.phar nevű archívumot, amibe belerak két fájlt. Ezt aztán lehet újra kitömöríteni valahova:
$phar->extractTo(__DIR__.'/phar',null, true);
Vagy épp lefuttatni: include 'phar://myphar.phar/index.php';. ezen kívül persze sok egyebet lehet vele. De valószínű, az egy másik cikk témája lesz.
PHP 5.4
Elértünk az utolsó fejezethez. Már ami a cikket illeti. A PHP természetesen tovább fog fejlődni. Ebben a verzióban a jelentős újítás főleg a trait-ek. Amikről később írok is. De vannak kisebb újdonságok is. Ezek mind hozzájárulnak ahhoz, hogy azt mondjam, újra beleszerettem a PHP-be.
Egész számok jelölése
Bevezették az egész számok bináris alakban történő megadását. Eddig ugye lehetett decimálisan, oktálisan és hexa-ban megadni. Ehhez jön most a bináris alak. Amit egy „0b”, azaz „nulla bé” prefix előz meg.
PHP 5.4 előtt
$hexa = 0x0F;
$octal = 017;
echo $decimal."<br />"; //15
echo $hexa."<br />"; //15
echo $octal."<br />"; //15
PHP 5.4 -ben
echo $binary."<br />"; //15
Tömbök
Ez nem egy hatalmas csoda, de a tömbök deklarációja egyszerűsödik. Aki programozott már JavaScriptben, annak nem lesz újdonság.
5.4 előtt:
$array2 = array(
'index1' => 1,
'index2' => 2
);
5.4 -ben
$array = [
'index1' => 1,
'index2' => 2
];
Ide sorolnám még az általam rég várt lehetőséget, hogy a függvények visszatérési értékét közvetlenül lehet indexelni anélkül, hogy előbb azt átadnánk egy változónak.
Függvény, ami tömböt ad vissza
{
return array(
'x' => 12,
'y' => 34,
'z' => 78
);
}
5.4 előtt
$z = $coords['z'];
5.4-ben
$z = coords()['z'];
Névtelen függvények
5.3-nál már írtam a névtelen függvényekről. És azt is írtam, hogy ott a függvényen kívüli változók nem elérhetők. Ilyennek számít a $this is, ha objektumon belül lett létrehozva a függvény. 5.4-ben annyiban változott a helyzet, hogy a $this változó, ami az objektumra hivatkozik, már elérhető. Valamint újabb metódusokat kapott a Closure osztály. Amivel utólag is változtatható, hogy a létrehozott függvény melyik objektumhoz tartozzon. És így a $this kulcsszó melyikre hivatkozzon.
private $test = '11';
public function test()
{
return function()
{
return $this->test;
};
}
public function setTest($test)
{
$this->test = $test;
}
}
$aa = new A();
$aa->setTest(5555);
$a = new A();
$f = $a->test();
echo $f().'<br />'; //11
$f = $f->bindTo($aa);
// /*vagy: */ $f = Closure::bind($aa, $f);
echo $f().'<br />'; //5555
Hogy ere gyakorlatban mikor lehet szükség, arra még nem jöttem rá. De mindenesetre adott a lehetőség.
Visszahívható függvények
Itt sem történt hatalmas változás, de a call_user_func() függvény használata elhagyhatóvá vált. Mert felváltotta egy újabb lehetőség, ahol a tömb is hívható lett.
$callback = array($object, 'method');
5.4 előtt
echo call_user_func($callback);
5.4 ben
echo $callback();
Beépített webszerver
Az 5.4 bevezetett egy beépített webszervert, ahol tetszőleges mappában indítható tetszőleges hoston és porton egy webszerver. A document root megadása nélkül az éppen aktuális mappa lesz a document root, amiből a szerver indítva lett. Ez jó, mert nem olyan egyszerű egyszerre két php verziót futtatni. Így viszont én is a jelenlegi 5.3-asom mellé feltelepítettem az 5.4-et. Az apache-csal az 5.3 indul, de indíthatok mellé 5.4-et. És párhuzamosan tesztelhetem a kettőt. Így tudtam leellenőrizni, mi az, ami egyikben még létezett, a másikban már nem. Vagy fordítva. A szerver indítása legegyszerűbben:
php -S localhost:8000
Ekkor elérhető lesz a root könyvtár a http://localhost:8000 oldalról. Persze ilyenkor nem apache fut alatta, tehát a speciális apache változókat és függvényeket el lehet felejteni.
Trait-ek
És elértünk a kedvencemhez. A trait-ek ötvözik a már korábban bevezetett megoldásokat. Mégis adnak újat. PHP-ben nincsen többszörös öröklődés. Azaz ha A osztály örököl B-től, nem örökölhet C-től is. Csak ha C-t B örökölte. Ez viszont nem mindig oldható meg. Főleg, ha nem mi írtuk a másik osztályt. Az osztályokhoz hasonlóan így bevezették a Trait fogalmát. Ami arra szolgál, hogy olyan osztályszerű, de mégsem osztály struktúrát hozhassunk létre, amit a use kulcsszóval egy valódi osztályban jelezhetünk, hogy annak a metódusaira és tulajdonságaira szükség lesz. Olyan ez kicsit, mintha fognánk egy osztály pár metódusát és bemásolnánk a sajátunkba. Csak ezt így megoldja helyettünk az értelmező. Nem történik tehát öröklés, az eredmény mégis ugyanaz. A korábbi konstansok mellett bevezették a __TRAIT__ konstanst is. Ami adott traiten belül tartalmazza a trait nevét. A __METHOD__ konstans ugyan a trait nevével tartalmazza a metódust, de a __CLASS__ már annak az osztálynak a nevét tartalmazza, amiben a trait fel lett használva.
{
public function getInfo()
{
return array(__CLASS__, __METHOD__, __TRAIT__);
}
}
class A {
use TraitA;
}
$a = new A();
var_dump($a->getInfo());
Mivel nem öröklés történt, az instanceof operátor nem használható annak ellenőrzésére, hogy az osztály megvalósít-e egy trait-et. A korábban említett reflection osztályok viszont ebben is segítenek.
if (in_array('TraitA',$ref->getTraitNames())) {
echo 'TraitA trait megvalósítva!';
}
Trait-eket is fel lehet használni singleton osztályokhoz
{
final private function __construct() {
}
public static function instance()
{
static $instance;
if (!isset($instance)) {
$instance = new self();
if (is_callable($instance))
{
$instance();
}
}
return $instance;
}
public function __clone()
{
throw new \BadMethodCallException('Nem klónozható osztály: '.get_called_class());
}
}
class A
{
use Singleton;
private function __invoke()
{
echo 'teszt';
}
}
$a = A::instance();
És ahogy említettem, többszörös öröklést is helyettesíti, mivel akárhány trait felhasználható:
{
public function __get($prop)
{
return $this->$prop;
}
}
class A
{
use Singleton, PublicGetters;
private $private = 'privát';
private function __invoke()
{
}
}
$a = A::instance();
echo $a->private;
$a->private = 'ez nem fog működni';
Ha véletlenül két felhasznált trait-ben ugyanaz a metódus létezik, akkor az egyiket át lehet nevezni. És meg lehet mondani, hogy az eredeti nevén melyik trait metódusa legyen meghívva. Kicsit továbbfejlesztve már azt is lehet, hogy az eredeti név ne legyen elérhető, mert van lehetőség a láthatóság módosítására is. Mindezt a use és as kulcsszóval lehet megtenni.
{
public function name()
{
return 'Alma';
}
}
trait FavoriteProgLang
{
public function name()
{
return 'PHP';
}
}
class Favorite
{
use FavoriteFruit, FavoriteProgLang
{
FavoriteFruit::name as FavoriteFruit;
FavoriteProgLang::name as FavoriteProgLang;
FavoriteProgLang::name insteadof FavoriteFruit;
FavoriteProgLang::name as private;
}
}
$fav = new Favorite();
echo $fav->favoriteProgLang().'<br />';
echo $fav->favoriteFruit().'<br />';
Jó, de mi van azokkal az osztályokkal, amiket nem trait-ként írt meg a fejlesztője, de én mégis szeretném többszörös örökléssel felhasználni? Erre is ad megoldást a trait, ugyanis a trait-ek örökölhetnek osztályoktól. Innentől kezdve pedig minden ugyanúgy működik, mintha eleve traitek lettek volna az osztályok:
{
public function method()
{
return __METHOD__;
}
}
class ParentClassName
{
public function name()
{
return __CLASS__;
}
}
trait TParentClassMethod extends ParentClassMethod { }
trait TParentCLassName extends ParentClassName { };
class A
{
use TParentClassMethod, TParentClassName;
}
$a = new A();
var_dump($a->method(), $a->name());
Ez a funkció csak a fejlesztői verzióban volt benne. Mint kiderült, ez egy hiba volt. És javítás címén törölték a traitek osztályoktól való öröklésének lehetőségét. Várható, hogy mutatok erre egy alternatív megoldást egy új cikkben.
Összefoglalás
Indultunk tehát egy nagyon alap megoldástól, ami személyes honlapok készítését volt hivatott segíteni. Kicsit összetettebb problémákat már nem tudott volna megoldani. Nem is az volt a feladata. Majd elkezdet fejlődni, és ahogy rájöttek, hogy ez jó, idővel nőtt a fejlesztők száma. Ezzel együtt a lehetőségek száma és a C forráskód mérete is. Felismerve hiányosságait, a fejlesztők egyre több modern technológiát építettek be és ezt pár év késéssel a PHP programozók is elkezdték felhasználni. Ki előbb, ki később. Most pedig ott tartunk, hogy olyan lehetőségek rejlenek benne, amit sokan nem is ismernek. Köztük én is, aki akkor döbbentem rá, mi mindent nem tudok, amikor elkezdtem kutatni a cikkhez szükséges anyagok után.
Jelen állás szerint szeptember 8-án jelenik meg hivatalosan az 5.4 béta 1-es verzió. Majd szép lassan jönnek az RC-k. A TODO lista szerint még van pár dolog, ami nincs megoldva benne. Viszont arra nem jöttem rá, lesz-e scalar type hinting. Ugyanis némely áthúzott elem már létezik 5.4 -ben. A weben sok helyen lehet olvasni róla. Viszont egy bugreport szerint, amit 5.4 -hez jegyeztek be, és válaszolt rá egy moderátor, nem létezik 5.4-ben sem. Írnak még pár újításról, ami a jelenlegi elérhető 5.4 -es verzióban még nincs. Nem gondolnám, hogy egy bétaközeli állapotból még sokat változna egy verzió. De ezt majd megtudjuk, ha kijött a végleges. Addig pedig örüljünk annak, amink van :) És a lehetőségnek, hogy még mik lehetnek egyszer.
Hozzászólások
Nagyon jó összefoglaló,
Nagyon jó összefoglaló, köszönet érte. A traitek nekem új volt. Most a namespacet próbáltram munkára fogni, de valamiért nem működik, talán nem értelmeztem helyesen a működését. A példakód:
nevter mappa :
A.php fájl :
class A {
function FA() {
return __METHOD__;
}
}
Core.php fájl :
use nevter\A;
$object = new A;
Fatal error: Class 'nevter\A' not found in E:\easyphp\www\nevter\Core.php on line 7
Köszönöm a segítséget.
Örülök, ha jól sikerült a
Örülök, ha jól sikerült a cikk.
A névterek használata önmagában nem elég. Az osztályokat be is kell tölteni. Vagyis a fájlokat. Ezt megtetted? Írtam autoload megoldást, csak a névtereshez nem írtam forráskódot. De kb ennyi:
{
require_once dirname(__FILE__) . '/ '. str_replace(array('_', '\\'),array('/', '/'), $class) . '.php';
}
Persze tetszés szerint lehet ezt változtatni. Attól függően, hol van a betöltő függvényed. Vagy netán külön osztály egy metódusában van. Ahhoz a
spl_autoload_register()függvény kellene még. De ez az elve.UI: A <code> helyett a <php> -t használd inkább php-hez. Szebb :) ( módosítottam )
UI 2: Hozzáteszem, neked a use -ra nem is lenne szükséged, mert mindkét fájlod ugyanabban a névtérben van.Így az osztály eleve elérhető. Akkor lenne értelme, ha a core-od maradna a globális névtérben. Akkor kellhetne a use-zal rövidíteni a meghívást.
A névterek használata
Nem. A Symfony 2 keretrendszerben nem kellett a fájlokat betölteni, legalábbis nekem nem kellett beilleszteni (ezek szerint a rendszer megtette). Ezért is hittem azt, hogy a namespace jelöli a fájl helyét, a use pedig a használatát.
Mert ott is van valamilyen
Mert ott is van valamilyen autoload megoldás ( már nem emlékszem milyen ), de az a saját, meghatározott nevű osztályaira vonatkozik. Arra, amit te hozol létre, nem. Ezért külön kell írnod hozzá egy autoload-ot.
Javaslom, előbb próbálgasd külön php fájlokban. Keretrendszer nélkül. És ha már minden világos, akkor próbáld alkalmazni keretrendszerben. De inkább nem ajánlom, hacsak nem saját keretrendszert írsz. Tartsd be a keretrendszer szabályait.
Kiváló cikk. Köszi az
Kiváló cikk. Köszi az összefoglalót.
Ez igen!
Tenyleg eleg jo kis osszefoglalo! Ritka a magyar anyagok kozott. Szep munka