ExtJS blog pont hu

Különböző mérési tesztek végzése közben arra a közhelyre jutottam, hogy az eval lassú, ám meglepődtem, hogy mennyire!? Például, ha egy egyszerű értékadást egymás után jó sokszor végrehajtjuk így is, úgy is, akkor közel ötször – hatszor (néhány alkalommal tizenötször) hosszabb futási időt kapunk eval használatával, mint nélküle: (Chrome-ban még durvább a különbség)

Az egészben a probléma az, hogy sokszor használjuk az eval függvényt, leginkább azoknál az Ajax hívásoknál, ahol végrehajtandó scriptet kapunk eredményül.

Vajon a JavaScript kitalálói miért gondolták azt, hogy a hónapok nullától a napok és az évek egytől kezdődnek. Megmagyarázható, de akkor sem logikus, hogy a 2008.11.21. -et miért new Date(2008,10,21) alakban kell létrehozni?

Szerencsére ExtJS-ben ezzel már nem kell foglalkozni, nagyon szépen elkészítették a string2date fordítót, a fenti logikai buktatót sem építették bele. :)

Jópofa ötlet volt ez a form layout. Teljesen felesleges lenne minden egyes input mező mellé létrehozni egy label objektumot.  Sokkal kényelmesebb, ha azt mondom, hogy az input mező egy tulajdonsága a címkéje és a konténer tulajdonsága, hogy hogyan jeleníti meg a beviteli mezők mellett (felett) a címkéket. Ám mégis kicsit szépséghibás, hogy a létrehozást segíti a rendszer, ám a további használat már nincsen megoldva… mosolyra deríti az embert, amikor az input mezőt el akarjuk tüntetni és a címkéje ott marad. Emellett szükségünk lehet futás közben a címke átírására is:

Ha egy gridhez hozzáadunk egy új sort, akkor alapértelmezetten odaugrik a néző. Ami általában nagyon hasznos. De előfordulhat olyan eset, amikor ez hátrányos. Opció nincs, amivel ezt ki lehetne kapcsolni, de megoldható, hogy átmenetileg kiiktassuk az ugrást:

Néha roppant idegesítő, ha az ember véletlenül lenyomja a visszatörlés gombot, miközben nem egy input mezőn áll. A böngésző úgy érzi, hogy a back gombot nyomtuk meg és emiatt az előző oldal töltődik be. Lehetséges, hogy ágyúval verébre effektus, de az Ext.History erre a problémára éppen megfelelőnek tűnik. Ha megnyomtuk a back gombot, akkor csináljunk úgy, mintha semmi sem történt volna. Mivel alkalmazásfejlesztéséről van szó, ezért ne is nagyon akarjanak a felhasználók a back gombbal visszalépni. (kitöröltem egy terméket, és a back gomb visszahozná azt?)

Eddig még nem használtam az ExtJS-ben a History-t. Lehetséges, hogy logikus a megvalósítás... de el nem tudom képzelni, hogy milyen hasznom származhat abból, hogy én hozom létre a segéd formot, benne a segéd inputmezővel, illetve a segéd iframe-mel. Arról már nem is beszélve, hogy ha nem IE alatt vagyok, akkor nem is kellene nekem iframe.

1. a form létrehozása, 2. a history bekapcsolása 3. a change esemény létrehozása, visszalépés esetén lépjünk ismét előre, 4 végül adjunk a History-hoz egy üres hash-t.

Hasznos lenne, ha az ExtJS egy új elem létrehozásakor ellenőrizné, hogy megfelelő azonosítót adtunk-e neki. Nevezhetnénk akár dummy checker-nek is, tekintettel arra, hogy ilyen ellenőrzéseket csinálhatna a felhasználó is, de ha ő egyszer nem csinálja, akkor jó lenne, ha legalább az Ext csinálna. :)

Egy furcsa jelenséggel találtam magam szembe, adott egy konténer, amelynek a layoutja border típusú, ám átméretezéskor a benne lévő elem mégsem követte annak méretét. A belső elem egy teljesen hétköznapi grid volt. Méret változással kapcsolatos események kezelését nem babráltam. Más elem nem volt az adott helyen.  És biztos ott, és biztos azt vizsgáltam. Hibakeresés közben már szinte mindent kitakarítottam a szóban forgó elemekből, csak az azonosítót nem... amik valami véletlen folytán ugyanazok voltak… és valóban:

JavaScript hibát nem kapok, csupán a végeredmény lesz egy kicsit furcsa.

Ma is egy néhány perces feladatot sikerült jócskán elhúzni.
Egy rendkívül egyszerű legördülő menü és az IE6 kombinációjából volt a problémám:

Az ötlet ezeréves, a kód ezeréves, a probléma meg az új CSS-ből adódott, ha a belső listában a listának, illetve a listaelemeknek nincs háttere, akkor IE alatt a mouseout olyan esetben is lefut, amikor arra nem számít az ember...

Valahogy mindig akkor hal le az extjs.com, amikor olyan bug-ba ütközök, amelyet valószínűleg már több száz másik ExtJS használó is megtalált, és a fórumban számtalan megoldást kínáltak a probléma orvoslására.
Az url-ek elkódolását nagyon olcsón oldották meg az ExtJS-ben.

A tömböt rosszul, az objektumot sehogy, a stringet jól jelenítette meg, a várt eredmény ez lenne:

Mivel nagyobb problémát okozott volna a szerver oldalon módosítani a kódot, kénytelen voltam az Ext.urlEncode -t felülírni:

Szükségem volt arra, hogy egymás alatt két felső toolbar jelenjen meg, némi keresgéléssel megtaláltam a megoldást, ami egyszerűbb lett, mint gondoltam:

Ám, nekem kicsivel rugalmasabb megoldás kellett, így a fenti onRender minimális átalakításával már tetszőleges toolbar adható hozzá:

Amikor megismertem a JavaScriptet, akkor a késleltetést még nagyon csúnyán oldatták meg:

szerencsére ez a kis "csúnyaság" után elterjedt a

forma is. Programozás szempontjából sokkal elegánsabb egy névtelen függvény bevezetése, mint egy string végrahajtása, ám olvashatóság szempontjából mindenképpen problémás.  Szinte elveszik az utasítás a sok töltelék között.

ExtJs-ben a késleltetést úgy oldották meg, hogy a "függvény típust" egészítették ki a következő metódussal:

Nincs mellébeszélés. Csak azt írjuk le, amit szeretnénk. :)