A legtöbb ExtJS tutorial azzal kezdődik, hogy a pixel.gif helyét felülírják. Ahogy több fórumban látom, sokakat zavar is, hogy az alapértelmezett érték ExtJS 2-ben még egységesen a http://www.extjs.com/s.gif volt. Engem meglepne, ha valóban az Ext-nél vizsgálnák, hogy milyen referrer-rel kérik le ezeket a képeket. De persze nem tudható. :) Már csak azért is érdemes felülírni ezt az értéket, hogy eggyel kevesebb hosztról szedjük a fájlokat. De mielőtt egy Ext.BLANK_IMAGE_URL = 'img/pixel.gif'; értékadással felülírnánk, érdemes megnézni a ExtJS 3-ban használt alapértelmezett megoldást:
Azaz IE6, IE7, illetve Air-ban használ már az Ext csak valódi képet. A többi böngésző ugyanis érti a fenti formát. Hagyjuk meg ezt mi is:
Alkalmanként hátránynak tűnt, hogy míg az asztali alkalmazásoknál könnyedén lehet elemeket forgatni, addig a weben ez rendkívül körülményes. (Több helyen szerver oldali képeket használtam erre)
Mostanában egyre több CSS-sel foglalkozó blogon kerül elő a forgatás témája. Számomra meglepő volt, hogy még IE 6 alatt is (ha nem is könnyedén, de) megoldható tetszőleges fokú forgatás.
(sok bejegyzés még csak a progid:DXImageTransform.Microsoft.BasicImage(rotation=X); filtert használja, amelyben 0, 90, 180, 270 szögek valósíthatóak meg, ellenben a DXImageTransform.Microsoft.Matrix(...) filterrel már a teljes forgatás kivitelezhető)
Azt persze meg kell jegyezni, hogy IE nem az elem középpontja körül forgat, így kénytelenek vagyunk forgatás után a pozíciót javítani. De ilyen apróságon már meg sem lepődünk. :) Ám a többi böngésző sem büszkélkedhet nagyon, egyáltalán nem értem, hogy miért kell minden böngészőnek más-más property-t használni ugyanarra. Gondolom sokat gondolkodhattak az Operánál a 10.5 kiadása előtt, hogy vajon használják a szabvány transform property-t, vagy álljanak be a sorba és a -o-transform alakot használják. Gratulálok nekik. :)
Túlzottan nem mentem bele, csak próbálgattam a lehetőségeket: http://stack.hu/extjs/rotate.php
Még márciusban Budapest.JS néven indult egy remek kezdeményezés. Havonta egy aklalommal 3-4 előadást tartanak JavaScript témában! A mostani alkalmon az Ext.core –ról is volt egy előadás.
Fejér Sándor: Ext.core - Egymagos kiterjesztés
Az előadáshoz tartozó PDF: http://theba.hu/Presentations/Ext.core.20100414.pdf
További előadásokhoz tartozó videók megtalálhatóak itt: http://palocz.hu/taxonomy/term/93
Érdekes témák, érdekes előadások, JavaScript iránt érdeklődőknek kötelező! :)
Nagy érdeklődéssel figyelem a HTML5-ről, illetve a CANVAS elemről szóló jóslatokat. Nincs kétségem, hogy még szép jövő áll előttük. Már régóta terveztem, hogy legalább egy hello world típusú példát összedobok magamnak, de idő sem volt rá, illetve érdekes minta feladatot sem sikerült kitalálni.
Igaz, miután eszembe jutott, hogy milyen jópofa lenne Mandelbrot halmazokat rajzolni rákerestem a neten és láttam, hogy előttem már vagy százan megcsinálták. :) Mindegy... érdekes feladatnak tűnt. http://stack.hu/mandelbrot/
Ja, és megfelelő böngésző szükséges hozzá! :)
Tetszik, ahogy az ExtJS-ben megoldották az átméretezést, véleményem szerint kellően rugalmas. Egy-egy komponens átméretezést egy külön Resizable elem végzi. Létrehozásakor megadjuk az komponens id-ját, illetve az átméretezés konfigurációját. (minimum, maximum méret, átméretezés iránya, dinamikusan változzon az elem mérete, vagy csak egér felengedése után, átméretezés közben legyen-e animáció, tetszőleges méret helyett léptetés stb.)
Egy sima TextArea-nál egyszerű dolgunk van, létrehozzuk a szövegmezőt, majd a Resizable elemnek megadjuk az ő azonosítóját, illetve az átméretezés mikéntjét. Annyit emelnék ki egyedül, hogy néhány elem átméretezéséhez szükség van egy befoglaló div-re, ilyen a textarea is, emiatt van szükség a wrap: true megadására:
HtmlEditor-nál már kicsit bonyolultabb a helyzet...
Nem tudom miért, legalább félévente egyszer belefutok abba a hibába, hogy megfeledkezem arról, hogy JavaScript-ben a String replace alapértelmezetten csak az első előfordulást cseréli. Az első előfordulás leginkább abból következik, hogy a replace nem stringet vár az első paraméterként, hanem egy reguláris kifejezés, ahol külön paraméter jelzi, hogy több előfordulásról van-e szó.
Találkoztam már olyan megoldással is, ahol a split és a join kombinációját használta valaki a replace helyett, de ez semmiképpen sem szép megoldás: src.split('foo').join('bar');
Gyakran vannak olyan Ajax hívásaim, amelyek esetleges késleltetése nem okozna semmiféle problémát akkor, ha ezzel fontosabb műveleteket előnybe részesíthetünk. Például az, hogy félpercenként vizsgáljuk, hogy kaptunk-e új üzeneteket kevésbé fontos akkor, ha éppen mi szeretnénk küldeni egy üzenetet.
Ennek vizsgálatához szükségem volt egy olyan függvényre, amely megadja, hogy van-e most futó Ajax hívás. Először még az Ext.Ajax eseményeihez rendeltem hozzá egy számlálót, de ezt már az elején éreztem, hogy ágyúval verébre effektus.
Utána az Ext.lib.Ajax.isLoading(...) függvényt szerettem volna általánosítani. Ám eközben észrevettem, hogy az Ext.lib.Ajax.poll pont az, ami nekem kell. (ez egy olyan objektum, amelynek elemei egy-egy Ajax híváshoz tartozó setInterval elem, az Ajax hívás befejezésekor ExtJs verziótól függően az elem vagy törlődik, vagy null lesz) Tehát abban az esetben, ha létezik a poll objektumnak eleme, amely nem null, akkor létezik folyamatban lévő Ajax hívás, különben nem létezik.
Ha egy ExtJS-sel készült alkalmazásban nyomtatásról van szó, akkor vagy PDF-et használok, vagy a kinyomtatandó tartalmat létrehozom egy iframe-ben, majd az iframe-t nyomtatom ki. Iframe nyomtatásával nem is lenne gond, de mégis érdemes figyelni az IE sokadik hülyeségére, miszerint ha nem kapja meg az iframe a fókuszt, akkor nem az, hanem a teljes document kerül nyomtatásra.
