ExtJS blog pont hu

Gyakori jelenség, hogy megszokásból egy űrlap adatait a Ctrl+S billenytűkombinációval akarom elmenteni, és ilyenkor feljön a böngésző Save As ablaka. Néhány sorral kezelhető ez a probléma:

A stopEvent: true-nak köszönhetően a böngésző saját eseménye nem hajtódik végre. (csak zárójelben az IE-nek néhány esetben ez is bonyolult, a Ctrl+S-nél éppen működik, de az F1-nél például nem)

Az egér jobb klikk lekezelése (a context menü előhívása) kifejezetten kényelmesen lett megvalósítva az ExtJS-ben, ám valamiért nem minden elemhez készítették el ezt alapértelmezetten. Nekem nagyon hiányzott a szimpla panel tartalmi részénél. Azaz, valami ilyesmire volt szükségem:

Nem gondoltam volna, hogy valamikor az Ext.override -ot is felül kell írni. Akasztjuk a hóhért:)

Az Object osztálynak van két speciális eljárása: a toString és a valueOf, első szövegként adja vissza az objektum tartalmát, míg a második valamilyen primitív értékként. Mindkét függvény felüldefiniálható, ám van egy olyan probléma, hogy IE alatt hiába definiáljuk felül ezeket, a for( i in obj ) ciklusnál nem lesz az iteráció része a felüldefiniált függvény.

Egy kicsivel valósabb példa:

A PropertyGrid egy olyan speciális EditorGrid, amelynek két oszlopa van: name és value, ahol a value oszlopban lévő értékek szerkeszthetőek. Amiért érdekes ez az osztály, hogy a használata sokkalta kényelmesebb, átláthatóbb mintha egy szimpla EditorGrid-del készítenénk el ugyanezt.
Sajnos szerkesztés nélküli verziója nincsen. Pedig lehetne... :)

Egy tetszőleges EditorGrid-nél, ha a beforeedit esemény hamis értékkel tér vissza, akkor nem jelenik meg a szerkesztőmező. Ezzel szinte már el is értük a readOnly PropertyGrid-et, ám nem túl elegáns, hogy a gridben a kijelölés csak a value oszlopon látszódik, illetve egy PropertyGrid a HTML felépítésekor kap egy class-t, ami az szokásos selModel-lel rosszul néz ki, így ezt is ki kell ütni.

Tehát:

Küszöbön áll a nap, az az egyetlen egy nap az évben, mely hivatalosan is a szereteté. Háromszázhatvanöt nap közül háromszázhatvannégy a gondjaidé, a céljaidé, munkádé, és a szereteté csupán egyetlen egy, s annak is az estéje egyedül. Pedig hidd el, Ismeretlen Olvasó, fordítva kellene legyen. Háromszázhatvannégy nap a szereteté, s egyetlen csak a többi dolgoké, s még annak is elég az estéje. - Wass Albert

Kellemes Karácsonyi Ünnepeket kívánok mindenkinek!

Valahol azt olvastam, hogy nem szükséges spórolni a függvényekkel. Ha úgy érzi az ember, hogy egy kétsoros függvényre szükség van, akkor hozzuk létre azt a függvényt. És nekem tényleg többször szükségem volt már arra, hogy egy fában az egyik elem gyerekeit töröljük:

ExtJs-ben egy beviteli mezőnél akkor fut le az változás esemény, ha az adott mezőről lemegyünk. Ami többé, kevésbé megfelelő viselkedés, ám egy TriggerField-nél, például egy dátumválasztónál jó lenne, ha a megjelenő naptárban egy dátum kiválasztása után is lefutna a változás esemény.

Szeretem a JavaScript-nek gyenge típusosságát. Hihetetlen rugalmassá teszi a benne készült eszközöket, ám mindig megvan a veszély, hogy egyszerű elírás felkutatása is hosszú és fáradságos feladat lehet, miközben más nyelvekben a fordító rögtön kidobja a hibát a típuskülönbségek miatt.

Amikor meglátom a képernyőn a [object Object] felíratot, akkor sejthetően belefutottam egy hasonló problémába. De most nem én, hanem az Toolbar készítői.

Egy eszköztár, benne egy üres elem:

Gyakorlatban hamarabb előjön, mint azt gondolnánk:)

Valamiért a TabPanel kirajzolásnál lefut a tabchange esemény:

Először arra gondoltam, hogy majdhogynem logikus, mivel az inicializálásnál az activeTab Number típusú, míg utána Panel típusú lett. Azaz valóban történt változás. Ám a következő átalakítás után sem javult a helyzet:

Sokat gondolkodtam azon, hogy miért így oldották meg az autoHeight-ot?
Miért használnék valamikor is autoHeight=false-t? ("Nem tudom a magasságot, de nem is szeretném, hogy az ExtJS kiszámolja!")

Vegyünk három esetet:

• Megadom a konkrét magasságot, ekkor az autoHeight érték nem számít.
• Olyan konténerben van az elem, ahol a konténer határozza meg a magasságot. Itt az autoHeight igaz érték elrontja az elem magasságát. Vagy bug, vagy ficsör, mindegy, a lényeg, hogy nem használható.
• Végül, az az eset, amikor sem az elemnek nincs megadva a magasság, sem a konténer nem határoz meg magasságot. De ilyen esetben nem lenne alapértelmezett, hogyha nincs magasság, akkor az ExtJS magától meghatározza?

Valahogy az az ember érzése, hogy felesleges ez a property, ExtJS-nek is kellene tudnia, hogy mikor kell automatikus magasság.