Honnan jött az Ajax, és hova tart?
Jim Ley vette nemrég a fáradságot, hogy bemutassa, mennyire nem számít újdonságnak az Ajax fejlesztés, és felnyissa a szemünket, hogy miért is most lett slágertéma. Úgy tűnik, hogy minden probélma gyökere az, hogy kevés a kliens oldali szkriptekben profi fejlesztő, és nem is alakultak ki igazán ilyen közösségek - a Perl, PHP vagy Java közösségekkel összehasonlítva -, és így nem termelték ki a megfelelő szaktudású fejlesztőket. Érdekes módon éppen erről folyt az eszmecsere nemrég a nyílt forrású tartalomkezelők nemzetközi levelezőlistáján is a böngészőbe ágyazott vizuális szövegszerkesztők kapcsán.
Amellett a nyilvánvaló tény mellett, hogy 1999-ben már megvoltak az Ajax alapjait képező technológiák Jim azt is megmutatja, hogy még sokkal korábban is megjelentek ilyen megoldások, egy 1996-os levélre hivatkozva, mely demonstrálta, hogy miként lehet űrlapokkal és keretekkel elérni az oldal újratöltése nélküli frissítés hatását. Tehát a techika nem új, mégis most jutott el a köztudatba. Ezt Jim szerint annak köszönheti, hogy korábban nem volt egy a piacot uraló kliens, amire fejleszteni lehetett, amikor pedig mégis kialakult a Microsoft egyeduralma a böngészők terén, éppen nem volt pénz az ilyen fejlesztésekre, a dotcom lufi kipukkanása után meg kellett húzniuk magukat a cégeknek.
Mostanra mindenesetre olyan webes óriások alakultak ki, mint a Google, akik Ajax fejlesztései hatására gyakorlatilag kénytelenek a böngésző gyártók a támogató technológiát beépíteni, gondoljunk csak a nemsokára megjelenő Opera 8-as kiadására. A Microsoft böngésző monopóliuma szerencsére múlni látszik, de Jim szerint nem is ettől kell tartani az Ajax fejlesztést illetően. Sokkal inkább a szoftvergyártó következő 7-es verziójú kliensétől félhetnek a szkriptek kialakítói, hiszen az szinte elkerülhetetlenül új hibákkal érkezik majd, és a fejlesztőknek igazodniuk kell ismét.
Minden „marketing” ellenére sem lehet persze mindenre megoldás az Ajax alapú fejlesztés. Az olyan webhelyek esetében, ahol nem tartózkodik sokáig a felhasználó egy adott oldalon - tulajdonképpen egy webes alkalmazás területén -, ott nincs értelme ebbe fektetni az energiáinkat, hiszen nem válik kényelmesebbé a látogatók számára a szolgáltatásunk elérése.
Ha mégis adaptálásába vágjuk fejszénket, érdemes megfogadni Thomas Baekdal tanácsait, aki többek között rámutat, hogy innentől kezdve alkalmazás fejlesztőkké léptetjük elő magunkat, és nem csak a működést, hanem a megjelenést is az asztali alkalmazásoktól elvárható módon kell kialakítanunk. Természetesen ezeket a tanácsokat úgy ültetjük a gyakorlatba, ahogy értelmezzük, illetve ahogy képesek vagyunk, de Thomas arról is gondoskodott, hogy egy névjegykártya szerkesztő alkalmazás példáján keresztül jó tippeket szerezhessünk a használható Ajax kialakítást illetően. A példaalkalmazás elemzésében kitér a fontosabb tervezési szempontokra is.
■ Amellett a nyilvánvaló tény mellett, hogy 1999-ben már megvoltak az Ajax alapjait képező technológiák Jim azt is megmutatja, hogy még sokkal korábban is megjelentek ilyen megoldások, egy 1996-os levélre hivatkozva, mely demonstrálta, hogy miként lehet űrlapokkal és keretekkel elérni az oldal újratöltése nélküli frissítés hatását. Tehát a techika nem új, mégis most jutott el a köztudatba. Ezt Jim szerint annak köszönheti, hogy korábban nem volt egy a piacot uraló kliens, amire fejleszteni lehetett, amikor pedig mégis kialakult a Microsoft egyeduralma a böngészők terén, éppen nem volt pénz az ilyen fejlesztésekre, a dotcom lufi kipukkanása után meg kellett húzniuk magukat a cégeknek.
Mostanra mindenesetre olyan webes óriások alakultak ki, mint a Google, akik Ajax fejlesztései hatására gyakorlatilag kénytelenek a böngésző gyártók a támogató technológiát beépíteni, gondoljunk csak a nemsokára megjelenő Opera 8-as kiadására. A Microsoft böngésző monopóliuma szerencsére múlni látszik, de Jim szerint nem is ettől kell tartani az Ajax fejlesztést illetően. Sokkal inkább a szoftvergyártó következő 7-es verziójú kliensétől félhetnek a szkriptek kialakítói, hiszen az szinte elkerülhetetlenül új hibákkal érkezik majd, és a fejlesztőknek igazodniuk kell ismét.
Minden „marketing” ellenére sem lehet persze mindenre megoldás az Ajax alapú fejlesztés. Az olyan webhelyek esetében, ahol nem tartózkodik sokáig a felhasználó egy adott oldalon - tulajdonképpen egy webes alkalmazás területén -, ott nincs értelme ebbe fektetni az energiáinkat, hiszen nem válik kényelmesebbé a látogatók számára a szolgáltatásunk elérése.
Ha mégis adaptálásába vágjuk fejszénket, érdemes megfogadni Thomas Baekdal tanácsait, aki többek között rámutat, hogy innentől kezdve alkalmazás fejlesztőkké léptetjük elő magunkat, és nem csak a működést, hanem a megjelenést is az asztali alkalmazásoktól elvárható módon kell kialakítanunk. Természetesen ezeket a tanácsokat úgy ültetjük a gyakorlatba, ahogy értelmezzük, illetve ahogy képesek vagyunk, de Thomas arról is gondoskodott, hogy egy névjegykártya szerkesztő alkalmazás példáján keresztül jó tippeket szerezhessünk a használható Ajax kialakítást illetően. A példaalkalmazás elemzésében kitér a fontosabb tervezési szempontokra is.
Szerintem ennek az is az
szerintem ennek az is az oka, hogy a webfejlesztők egyszerüen nem veszik komolyan a JavaScriptet, aminek meg az egyik oka az lehet, hogy a böngészőkben egy kattintással kikapcsolható a JavaScript támogatás és így félnek attól, hogy ha sok munkával elkészitenek egy projektet azzal később mindenféle problémájuk akad majd. A JavaScript amolyan mellékes dolognak számit, ami jó mert kényelmesen ellenőrzi pl. az ürlapokba beirt adatok helyességét, egy-két érdekes effektus előállítására is nagyszerü, de igazán a lehetőségeit nem használják és nem veszik komolyan.
sütik
Szia, persze egyetértek