Nem igazán friss hús, de most kéne tanulni, úgyhogy most próbáltam ki a NetBeans legújabb verzióját. A php és javafx verzió érdekelt, a Java-ról egyrészt elhiszem hogy nagyon jó, másrészt kicsit mostanában (sajnos?) mellékvágányra került nálam a téma, a többihez (ruby, c/c++) pedig nem értek.

Először 1-2 hete a NetBeans for PHP-t néztem meg, hát mit ne mondjak rég láttam ilyen jó php környezetet. Na nem mintha sokat várnék, de ami kell azt tudja: syntax highlight megy, rendesen működik az auto-completion (legalábbis kohana-s cucchoz, aminek ugyebár kb ugyanúgy működik az autoloadere mint a ZF-é, ez mondjuk lehet benne van a dologban), ráadásul normális a sebessége is. Összehasonlításképp: eclipse-ben az autoloader hol megy, hol nem, és ha megy, akkor is döglassú.

Ezen kívül kipofozták a JavaScript syntax highlightert, 6.1-ben még elég pocsék volt, mostmár rendesen megy (legalábbis én nem tudtam olyan kódot produkálni a rászánt 2 perc alatt amitől megfeküdt volna). Ráadásul a standard DOM API-hoz van autocompletion és még popup doksi is, szóval igazán tisztességesen meg van írva a js támogatás is, nem nagyon láttam még ehhez hasonlót. Ha már így benne voltam megnéztem a CSS szerkesztőt is. Na itt lepődtem meg igazán, ugyanis nem csak hogy rendesen működik, hanem egy dobozban megjelenítni on-the-fly hogy az éppen szerkesztett CSS utasítás hogyan fog formázni egy divet, ráadásul ez is normális sebességgel működik - csöpögök.

Szóval PHP téren jelenleg nagyon odaveri a netbeans az eclipse pdt-t, érdemes váltani.

Ezután jött a JavaFX-es NetBeans, ettől már nem voltam annyira elragadtatva. Telepítés közben kicsit meglepődtem, mert a telepítő nem kérdezte, hogy hova akarom rakni a cuccot, hanem észrevette hogy már van egy NB telepítés a gépen (a php-s) és abba másolta a javafx-es cuccokat is. Gondolom ez nem javafx-specifikus dolog, hanem úgy alakították át a netbeans-t hogy egy gépen csak egy telepítés lehessen. Nem vagyok túl boldog tőle dehát istenem, ettől még nem dől össze a világ.

Viszont ez a JavaFX támogatás sehogy nem akar jó lenni. Még mindig nincs hozzá normális drag&drop editor, amit annak neveznek az annyi, hogy ráklikkolok egy gombra és a kódba beilleszt az adott widgethez egy sample kódot - akkor is, ha épp rossz helyen áll a kurzor és syntax erroros lesz a kód. Van még újításként egy preview nevű ablak amiben elvileg látjuk hogy hogy fog kinézni az éppen szerkesztett UI, ez elvileg nem lenne rossz csak ahogy néztem kicsit döcögve működik. Ezen kívül még mindig vannak olyan banális hibák, mint pl az hogy ha a forráskód hibás volt, aztán javítom, attól még a fájl ikonja továbbra is hibásnak jelzi, meg ilyesmi. Na nembaj legalább a kódszerkesztő jobban működik mint 6.5-ben.

Egyébként bekerült a netbeans-be egy olyan feature hogy az internal frame-eket lehet undockolni és akár másik workspace-re helyezni, ezt én pl az eclipse-ből nagyon hiányolom, úgyhogy most ennek szintén örülök:)

Elindult a KForm projekt, egy új formolós modul Kohana-hoz. Nem egy nagy dolog, view scriptek nélkül 150 sor az egész, de szerintem sokat tud, és egész jól használható. A wikiben van hozzá tutorial, szerintem nagyjából minden le van benne írva, kéretik próbálgatni, tesztelgetni, aztán bugreportokat kérek a projekt oldalán, vagy akár itt is. Kohana v3-hoz van írva, amihez amúgy megjelent egy egész használható wiki, úgyhogy mostmár kicsit könnyebben tanulható a cucc.

A view scriptek szintjén azért hoztam a formám, csapnivalóan rondák :) de ha minden igaz Vil már patkolja.

Ja, igen. Ez a 100. poszt a blogon :)

16.-án némi csúszás után megjelent a Kohana framework 3.0 verziója - kódnevén "renaissance". Az új verzió tulajdonképpen egy teljesen új keretrendszert hozott (majdnem az egészet újraírták), ami ugyan sokmindenben hasonlít a 2.x-es szériára, de egyáltalán nem kompatibilis vele. Átalakították a konfigurációt, minimálisra csökkent a szekvenciális bootstrap kód (index.php meg még ami utána jön), ami van, annak is a nagy része olyan dolog, ami eddig a konfig könyvtárakban volt.

Sokkal egyszerűbbé vált az autoloader: korábban dedikált könyvtár volt a különböző feladatokra, controllers, models, libraries, stb. Most gyakorlatilag az egészet benyomták egy classes könyvtárban, amin belül az autoloader rendkívül egyszerűn működik - úgy, mint a zend frameworkben (tehát a My_Custom_Something osztályt a classes/my/custom/something.php fájlban keresi). Ennek a működésnek van egy olyan előnye a 2.x-hez képest, hogy ott nem volt hova tenni a "business object"-eket, a libraries könyvtárba volt érdemes rakni őket (az volt egy olyan "egyéb" kategória az autoloadingba, amire semmilyen elnevezési konvenció nem vonatkozott), viszont a ilbraries-en belül nem lehetett alkönyvtárakat létrehozni - ezért aztán én 2.x-re nem is alapoznék igazán komoly projektet. A 3.x-ben a classes alatt azt csinálok amit akarok, így nincs ilyen gond. Szóval a 3.0 verzióban azt hiszem kinőtte a framework egy pár maradék gyermekbetegségét.

A sok egyszerűsítésnek egyébként meg is lett az eredménye a teljesítményben, eddig se volt egy erőforrás-igényes keretrendszer a kohana, de a 3.0 (install utáni) memória-fogyasztása ~1mb-ra csökkent (a 2.x-ben ez ~1.4mb) - örülünk.

Mivel a 3.0 verzió valójában nagyjából egy új framework-öt jelent, ezért még folytatják a 2.x sorozat fejlesztését is, szintén pár napja jött ki a 2.4 beta1, és úgy tűnik, nem sokáig lesz béta.

Nem rég már írtam a php statikus metóduskezeléséről. A php 5.3-ban (aminek egyyébként most jelent meg a 3. RC kiadása) a dolog tovább bonyolódik, ugyanis bejön a static kulcsszó, ami a self-et egészíti ki/helyettesíti, késői kötést biztosít a statikus metódusoknak. Ha jól látom ez ugyanúgy fog működni, mintha az osztály nevével hivatkoznánk a metódusra (Myclass::mymethod()).

Azt hiszem az a legjobb megoldás, ha nem használunk statikus metódusokat php-ben. Csak engem emlékeztet lassan a c++-ra a bonyolultsága?

A gravatar.com egy talán leginkább az OpenID-hez hasonló szolgáltatás, viszont annál sokkal egyszerűbb: ez összesen annyit biztosít, hogy egységes avatar-t használhatunk "bármely" (a gravatar-t támogató) portálon.

Nem nagy dolog, ahogy nézem nem is túl elterjedt az OpenID-hez képest, de azért a nagyobb CMS-ek támogatják, egyébként pedig pofonegyszerű integrálni, összesen pár sor, de akinek ez kényelmetlen, az használhat wrapper class-t.

A blogon az oldalsávban megjelent egy blogmarkok nevű doboz. Ide nem kerül majd komoly tartalom, csak egy-egy érdekes link, amit szerintem érdemes megnézni, de azért annyira nem fontos, hogy külön postot írjak róla. Olyan twitter/identi.ca jellegű "microblog" lenne a dolog, azok a cikkek és blogbejegyzések kerülnek majd ide, amiket éppen olvasok.

Nem tudom mások hogy vannak vele, de nekem hiányzott egy ilyen szolgáltatás a blogmotorból, meg már amúgy is régen fejlesztettem, úgyhogy épp ideje volt dolgozni rajta egy kicsit. Ma az admin felületet is kicsit kényelmesebbé, használhatóbbá tettem, ez az egyik olyan problémája a KBlog-nak, ami miatt még nem nyitom meg a forráskódját (persze van más is).

Nem tudom fel szeretné-e venni valaki rss-ben a microblogot, ha igen, akkor szóljatok, és írok neki feed-et.

PHP-ben van ugyan static kulcsszó, de ettől függetlenül a nem statikus metódusokat is meghívhatjuk statikusan. A legtöbben úgy tudják, hogy egy metódus belsejében annak alapján lehet eldönteni hogy statikus metódushívás történt-e vagy nem, hogy létezik-e a $this változó. Ez azonban sajnos nem mindig igaz.

Kicsit alaposabban körüljártam a dolgot, és írtam egy demót, letölthető innen. A demóban két osztály van, a B osztályban vizsgáljuk a $this-t, az A osztályból pedig B metódusát hívjuk. Nézzük, mit csinál az index.php:

A 7-8 sorban az index.php-ből hívjuk egy B típusú objektum metódusát, az eredmény nem meglepő, a $this B típusú objektum. Ezután a 11. sorban statikusan hívjuk B metódusát, itt a $this értéke NULL, ebben sincs semmi meglepő. A 14. sorban létrehozunk egy A típusú objektumot, a továbbiakban ezzel dolgozunk. Először A egy metódusából hívjuk B metódusát, itt a $this szintén B típusú, ez is magától értetődő.

Az érdekesség most jön. Az A objektum nem-statikusan hívott metódusából hívjuk B metódusát statikusan. Ekkor a B metódusában a $this egy A típusú objektum lesz - a hívó objektum, tehát a metódushívás környezete (!!).

Nem tudom hogy ez bug vagy feature, ha bug akkor ismert-e vagy nem, még nem jártam utána, de lehet hogy fogok. Elég durva, nehezen felderíthető hibák következhetnek ebből a viselkedésből.

Valószínűleg az történik, hogy a futtatókörnyezet metódushívásnál először a $this-t rakja rá a veremre, ha nem statikus a hívás. A metódus pedig innen veszi le a $this-t - vagy amit ott éppen talál - mikor szüksége van rá. Statikus híváskor persze nem kapják meg ezt a paramétert, és mikor szükség lenne rá, akkor leveszik a veremről amit ott éppen találnak. Ez most az A típusú hívó objektum. Ennek némileg ellentmond, hogy ha átadok A metódusának egy paramétert, akkor is az $a objektum lesz a B-ben a $this, pedig ez alapján a paraméternek kellene lenni. Nem tudom, hogy pontosan mi történik, 3 ötletem van:

* az interpreter leveszi az összes paramétert a veremről a metódushívás végén és átteszi máshova (miért tenné?)
* a $this változó nem első, hanem utolsó paraméterként adódik át, így a következő metódus a hívási listán azt találja a verem tetején. Ez se valószínű, az OO kódok nem így szoktak futni.
* a hívási listához tartozó $this objektumok külön veremben vannak, nem együtt a többi paraméterrel. Ez tűnik számomra a legvalószínűbbnek, bár ez is elég furcsa.

Majd ha jutottam valamire a dologgal akkor írok :)

Végül a teszt végén még A metódusát hívjuk statikusan, abból pedig B metódusát szintén statikusan, ilyenkor - nem meglepő - a $this értéke null lesz.

Némi unszolásra kipróbáltam a Komodo Edit nevű PHP IDE-t. Ez a Komodo-nak egy ingyenes, gtk-s változata, elég sok helyen lehet róla hallani, bár én az utóbbi időben inkább csak a "futottak még" kategóriába sorolják a témával foglalkozó fórumokon. Na nézzük mit tud.

A telepítéssel nincs semmi gond, parancssorból megy és kb 30 másodpercig tart, majd a program - egy közepes tudású környezethez méltóan - közepesen sokáig bootol, közben semmi splash screen, amit felróhatnánk neki mint hiányosságot, de nem tesszük :) Startup közben cache-eli a beépített php függvényeket és osztályokat (plusz a kiterjesztésekét) autocompletionhöz, örülünk. Egy NetBeans-szerű bemutató oldal jelenik meg linkekkel és néhány funkcióval, plusz egy oldalsó panel, alsó panel viszont érdekes módon nincs, és ez új projekt indítása után sem jelenik meg. Mikor elkezdünk gépelni nagyon lassú, laggol, ha van autocompletion, ha nincs, de pár sor után belejön és tűrhető lesz a sebessége. Objektum-orientált eszözök viszont sajnos nem igazán támogatottak, az osztályok mellett nincs outline, saját objektumokra nem megy az autocompletion. A html-css szerkesztője viszont okos, gyors, és jól használható, a javascript editor is megbirkózik bonyolultabb dolgokkal, ez +1 pont a NetBeans-hez képest. A hibakezelés viszont elég pocsék, a syntax error-t egyszerűen aláhúzza, de nem írja ki, hogy mi a hiba (mire lenne jó egy alsó panel...)

A kódszerkesztőt több részre oszthatjuk, ami nagyon jó, pont olyan, mint eclipse-ben. A beállításokat egy Preferences nevű menüpontban találjuk, és a felugró párbeszédablak pontosan olyan elrendezésű, mint az eclipse preferences... ezek a dolgok nekem valahogy nem szimpatikusak. Viszont az eclipse-el szemben alapból van benne full screen funkció.

Sajnos hiányoznak belőle olyan - komolyabb szoftver fejlesztéséhez szükséges - eszközök, mint go to definition, osztáyhierarchia mutatása vagy svn integráció, bár FTP-zni ügyesen tud. Meglévő projekthez könnyen tudjuk használni, elég, ha új projektet kezdünk, és a hozzá tartozó .kpf fájlt a projektünk könyvtárába mentjük, máris látni fogjuk az oldalsávban annak tartalmát, és dolgozhatunk vele.

Összefoglalva a Komodo Edit egy közepes tudású IDE, mely kisebb, pár napos projektekhez jól használható, főleg ha kevés a php és inkább a kliens-oldali kódon van a hangsúly, viszont csapatban, céges környezetben szerintem nem érdemes használni.

Megjelent a Zend Framework 1.8. A ZF - a kismillió php framework közül - talán a legfejlettebb és legkiemelkedőbb. Ha másért nem, legalább azért érdemes megemlíteni, mert a Zend cég fejleszti, akik a php nyelvet is karbantartják.

A ZF új verziója sok újdonságot hozott, olyanokat, melyeket én eddig nagyon hiányoltam. Ilyen például az alkalmazásunk struktúrájának felépítéséhez használható CLI, melyet a zf/bin/ könyvtárban találhatunk. Könnyen létrehozhatunk vele új projektet, azon belül új kontrollert vagy view scriptet. Fix fájlrendszert határoz meg a projektnek, ami szerintem szintén jó, nem szerettem, hogy eddig minden ZF tutorial-ban kicsit más volt a könyvtárstruktúra, más volt a .htaccess fájl, az index.php, stb. Új, objektum-orientált bootstrap került a frameworkbe, ez a Zend_Application osztály, így mostantól ez sem vesz el órákat új projekt kezdésekor.

Újratervezték az autoloader-t is (pontosabban jött egy új), mely képes különböző névterekhez különböző loadert rendelni, így kevesebb probléma van azzal, ha a projektünkben olyan komponenseket is használunk, melyek nem követik a Zend elnevezési konvenciókat.

Most találtam rá a php-blog.hu-ra. Nagyon színvonalas oldal, sajnos elég hamar kihalt (tavaly október óta nem született új post), pedig láthatóan lenne rá igény. Sajnos még mindig nem vagyok elájulva a hazai szakmai - és nem szakmai - blogélettől (mivel alig van).