ExtJS blog pont hu

A bevezetőbe eredetileg arról akartam írni, hogy logikusabb lett volna, ha a Viewport singelton osztályként működne, mivel hosszas tanakodás után sem találtam életrevaló példát, ahol egyszerre két/több Viewport-ot használnék. (A párhuzamosan több képernyő lekezelésére is inkább egy darab fit layout-os Viewportot használnék, és abban váltogatnám az aktív elemeket.)  Ám miközben az érveket, ellenérveket soroltam fel, rájöttem, hogy igaz az, hogy csak legfeljebb egyetlenegy példányt hozunk létre, de működésben szükséges, hogy pontosan ugyanúgy viselkedjen, ahogy a többi konténer elem. Felesleges csavar lenne, ha egyke osztályként működne.

Az persze továbbra is megmaradt, hogy én csak egy Viewport-ot használok, ahogy az is, hogy szükségem lehet arra, hogy azt közvetlenül elérjem. (megoldás persze a Ext.getCmp(viewport_id) is, ám ez szerintem rugalmatlan)

csak úgy, mert hasznos...

UPDATE: az eredeti script közel kétszer annyi futási idővel dolgozott, ezért le lett cserélve...

A legeslegelső JavaScript próbálkozásom - legalább tíz éve - egy képnél az egér események lekezelése volt. Egérrel a kép felé mentünk és megváltozott a kép. Nagyon örültem, amikor sikerült. :)  Rögtön a második script ezután az volt, hogy betöltöttem ezeket a képeket a memóriába, hogy ne csak a mouseover eseménykor induljon el a letöltés.

Nosztalgikus hangulatba kerültem, amikor azzal a feladattal szembesültem, hogy az egyik alkalmazásban lassú net esetén egy-egy kép zavaróan lassúan jön le, és ezért jó lenne az egyik CSS fájlban lévő képeket előre letölteni.

Az alap script-et még régebben az Ajaxian-on láttam, de két okból át kellett alakítani. 1. a JQuery-t lecseréltem Ext-base -re. 2. nekem csak egyetlen egy CSS fájlban lévő képekre volt szükségem, a teljes ext-all.css tartalmára nem.

A táblázatoknál kevés adat esetén gyakori, hogy a rendezést nem a szerver, hanem a kliens oldalon végezzük. Amellett, hogy a szervert is kíméljük, még gyorsabb is. Szöveges mezők esetében a rendezés az ékezetekre nincs felkészítve.

Sajnos a Store-ban nem az összehasonlító függvényt írhatjuk felül, hanem az összehasonlításhoz használt értéket. Szerintem az előbbi verzió rugalmasabb. Lásd. PHP usort függvényét.

Mindenesetre a magyar ékezetes szavak rendezését így is könnyen megvalósíthatjuk. Nem kell mást tenni, minthogy az adott szó helyett vizsgáljuk meg az ékezet nélküli verzióját. (és ha már ott vagyunk, akkor a kis-nagy betű különbségeket is hagyjuk figyelmen kívül)

Az ingyenes statisztikák közül vitathatatlanul legjobb a Google Analytics. Néhány soros HTML kód beillesztés után egész komoly rálátásunk lehet a látogatóink oldalon eltöltött viselkedéséről.
Az Ajax-os oldalak elterjedésének köszönhetően, megoldották, hogy tetszőleges url-t is szimulálhassunk a következő módon:

A fenti kódsort hozzárendeljük bármely eseményhez, amivel egy új oldalletöltést kapunk a statisztikában. (ablak megnyitása, tab váltás stb.)

Néha nehezen magyarázható meg az ügyfeleknek, hogy egy Grid-ben miért kell egyszerre lapozó is, meg görgetősáv is. Talán azért is, mert ezt én sem látom logikusnak. :)

Arra, hogy csak görgetősáv legyen, létezik több kezdeményezés is. (lásd. LiveGrid, vagy a BufferView) Ahhoz, hogy csak lapozó legyen, nem kell mást csinálni, mint meghatározni, hogy egy oldalra maximum hány sor fér ki, és csak annyit kell egyszerre megjeleníteni.

MySql alapértelmezetten nem érzékeny a kis és nagybetűkre, ami néha talán még előnyös is lehet. Ám vannak esetek, amikor nem, ilyen például az azonosító és jelszó bekérése. A BINARY kulcsszó megadásával szigoríthatjuk a vizsgálatot.

Az eredmény meg: 1, 0, 1, 0

Egy ablak vagy egy panel elemhez nem csak a szokványos bezár, összecsuk stb. eszköz gombokat lehet hozzárendelni, hanem még egy tucat másikat. Kérdőjelet, fogaskereket és még ki tudja miket... már sokadszorra fordult velem elő, hogy a "ki tudja mik"-en gondolkodtam, majd minden alkalommal eldöntöttem, hogy ezeket valahol összegyűjtöm.

A doksiban fel van sorolva a lista. Ám mégiscsak többet nyújt, ha az ember látja is maga előtt ezeket.
Az, hogy miket használhatunk, legegyszerűbben úgy nézhetjük meg, hogy a css szabályok között kikeressük azokat, melyek .x-tool-akármi alakúak.

Az ExtJs előnyeit leginkább akkor látja meg az ember, ha egy feladatot a körülmények miatt más eszközökkel kell megoldani, és tudja, hogy mindez Ext-ben csupán néhány sor lenne.
E gondolat nemrég az elemek pozicionálása okán jutottak eszembe.

Például hozzunk létre egy 300x300-as piros négyzetet és tegyük a képernyő közepére:

A második utasításhoz némi magyarázat:
Az újonnan létrehozott elemet helyezzük el a document.body-hoz képest úgy, hogy a body közepe illeszkedjen az elem közepéhez.

Ha azt szeretnénk, hogy a böngésző átméretezése után is legyen középen, akkor az alignTo függvény helyett használjuk az anchorTo függvényt.

Vegyünk egy másik példát, hozzunk létre két 100x100-as négyzetet, és tegyük úgy a képernyő közepére őket, hogy egymás mellett helyezkedjenek el és köztük legyen 10 pixel távolság.

Tömb elemeinek összekeverése: