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

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.

Az utóbbi napokban ismét kicsit aktuálisabbá vált a progtut.net 2.0 probléma, a portálon mostanában kicsit felpezsdült az élet (by elodani:)), így most már tényleg ideje lenne megírni egy korszerűbb és használhatóbb portált.

Az új portált Java-ban szeretném írni, php + kohana párossal valószínűleg kisebb meló lenne (mivel abban már több tapasztalatom van), de a java nyelvet sokkal jobban szeretem, és hiszek benne, hogy gyorsabb mint a php. Viszont nekem eddig úgy tűnik, hogy a php frameworkök kiforrottabbak és alkalmasabbak portálfejlesztésre mint a java frameworkök, jobban és egyszerűbben megoldják a tipikus webfejlesztéssel kapcsolatos problémákat. Ahhoz képest hogy milyen fapados technológia a php nagyon jók a keretrendszerek (amikkel találkoztam: CodeIgniter, Kohana, Zend, Yii). Az általam ismert java frameworkök közül valamelyik általam fontosnak tartott feature mindegyikből hiányzik.

Na de nem adom fel, keresem a megfelelő java keretrendszert. Lássuk mit szeretnék:

* layout page / content page rendszer egyszerűen megvalósítható legyen és emiatt ne kelljen lemondani az egyéb feature-ökről

* a fenti viselkedés egyszerűen letiltható legyen egyes action-ökben, hogy lehessen ajaxozni és rss feed-eet generálni

* szépek legyenek az URL-ek, kohana/CI-szerűen az URL egyes részeit át lehessen adni paraméterként a controllernek

* a request paramétereket automatikusan rakja be a framework egy bean-be, és legyen kiforrott annotáció / xml alapú validációs mechanizmus

* lehessen vele Java objektumot JSON-ba konvertálni

* ne akarjon beleszólni a framework a layout-ba, ne határozza meg az oldal struktúráját

* esetleg még az jó lenne, ha a frameworköt lehetne GWT-vel integrálni

Úgy nagyjából ennyi. Szerintem nem kérek sokat...
Eddig a struts-ot és a stripes-t néztem, mindkettő több pontnál elvérzett, de szerencsére van még miből válogatni :)

Persze ez nem azt jelenti, hogy a java nem alkalmas webfejlesztésre. Inkább arról van szó, hogy a java frameworköket inkább nagy alkalmazásokhoz, belső céges ügyviteli portálokhoz, rengeteg űrlap gyors (automatizált) kezeléséhez fejlesztették, így nem a progtut.net-szerű portálok jelentik a tipikus feladatokat. Nyilván kiváló technológiák a GWT meg a JSF, de arra alkalmatlanok, hogy az egész progtut.net-et ezekre alapozva írjam meg.

Ha valaki tud a fenti kritériumoknak megfelelő Java keretrendszert, az ne tartsa magában :)

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.

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.

Mikor egy akármilyen szoftvert fejlesztünk, általában megerősítést kérünk a felhasználótól, mikor az egy fontos és/vagy nem visszaállítható műveletre ad utasítást. Ilyen lehet egy táblázatból egy elem törlése, vagy akármi. Desktop alkalmazásoknál ezen különösebben nincs mit túltárgyalni, megjelenítünk egy message boxot vagy valami hasonlót, és megkérdezzük a felhasználótól, hogy valóban végre akarja-e hajtani az adott műveletet. Webalkalmazások fejlesztésekor alapvetően két lehetőségünk van a visszakérdezésre:
* egy javascript confirm dobozban kérünk megerősítést, vagy valamilyen kliens-oldali DOM-manipulációval megjelenítünk egy megerősítő dobozt
* elküldjük a HTTP-kérést, de nem végezzük el egyből a műveletet, hanem előtte egy új oldalon kérünk megerősítést.

Az első módszernek több előnye van, pl mivel a kliens-oldalon történik a megerősítés, nem terhelik a szervert a félrekattintások, szebben is néz ki, a felhasználó számára is kevésbé körülményes.

Azonban sokkal kevésbé biztonságos, könnyen adhat lehetőséget súlyos következményekkel járó XSS támadásra. Tegyük fel, hogy valaki olyan spamet küld, amiben van egy link, ami mondjuk egy közösségi portál "profil törlése" funkciójának címére mutat. A felhasználó rákattint, nem nézi meg előtte hogy hova mutat a link, és már törölte is az accountját, mivel a javascriptes megerősítést kikerülte a spammer.

Tehát kritikus műveleteknél mindig oldal-újratöltéssel (vagy ajax-szal) érdemes megerősítést kérni, így mindenképp látja az user hogy mit csinál. A példánál maradva, mikor a felhasználó mondjuk a "profil törlése" linkre kattint, akkor tároljuk szerver-oldalon - célszerűen sessionben - hogy rákattintott, kérjünk megerősítést, ha azt megkaptuk, akkor nézzük meg, hogy a folyamat szabályosan zajlott-e (nem egy spam-ből jött a megerősítés) majd csak azután végezzük el a műveletet.

Szép dolog az eclipse, örülünk a hihetetlenül flexibilis plugin-rendszernek, és annak, hogy bármit ki tudunk hozni belőle, de azért jó, ha egyszer össze tudunk pakolni egy jó konfigot, és utána csak óvatosan piszkáljuk.

Sajnos az utóbbi időben többször tapasztaltam, hogy az ingyenes eclipse pluginok között nagyon sok az instabil. Ilyen volt a FreeMarker plugin, a SmartyPDT és a VisualSwing4Eclipse (bár erre még senki nem is mondja, hogy stabil). Sajnos mindegyik nagyon gyakran összeomlott, félúton meghalt a syntax highlight, stb. Szóval érdemes jó alaposan tesztelni, próbálgatni egy plugint, mielőtt elkezdenénk mindennapi munkánk során használni. Ha mégis felraktunk valamit, amit nagyon nem kellett volna, akkor az eclipse plugins/ és features/ könyvtárában kicsit takarítva visszaállíthatjuk az eredeti állapotot.