PagingToolbar.pageSize

2009.05.16. 10:57 stack

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.

UPDATE: az elmúlt időszakban vissza-vissza nyúlam ehhez a kódhoz, apró változtatások több alkalommal is történtek. Egy idő után úgy döntöttem, hogy annyi apróság volt, hogy a mintakódot itt is lecserélem.

Első és legfontosabb, hogy mindenhol plugin-ként használom, így könnyebben hordozható. Eredetileg a Math.floor helyett parseInt –et használtam, eredmény szempontjából lényegtelen, de így mégis beszédesebb. Látszódik, hogy szándékosan lefelé kerekítünk. Az első verzió még használta a render eseményt is, ám az felesleges volt, mivel a grid létrehozáskor a resize esemény is lefut. Továbbá érdemes figyelni azt is, hogy szükséges-e az újratöltés, vagy sem, ha a limit nem változik, akkor felesleges.

Azaz:

var pageSizePlugin = {
    init: function (cmp) {
        cmp.fixPageSize = function () {
            var limit = Math.floor(this.getView().scroller.getHeight() / 21);
            if (limit && this.getBottomToolbar().pageSize !== limit) {
                this.getBottomToolbar().pageSize = limit;
                this.getStore().load({params: {start: 0, limit: limit}});
            }
        };
        cmp.on('resize', cmp.fixPageSize, cmp, {delay: 10});
        cmp.getBottomToolbar().pageSize = null;
    }
};

var store = ...;

var grid = new Ext.grid.GridPanel({
    ...,
    store: store,
    bbar: new Ext.PagingToolbar({
        store: store,
        displayInfo: true
    }),
    plugins: [pageSizePlugin]
});

Nézd meg élőbe: http://stack.hu/extjs/page_size_plugin.php

36 komment

Címkék: plugin toolbar grid pagesize paging

A bejegyzés trackback címe:

https://extjs.blog.hu/api/trackback/id/tr741124651

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

forraikris 2009.05.16. 23:17:08

Én is hasonló problémával találkoztam; lapozó nélkül, vagy laponként 500 sorral kellene megjeleníteni soronként 30-40 oszlopot. Plusz nehezítés, hogy a sorokat tudni kellene kijelölni (checkbox model).

Először kipróbáltam a Buffer Grid-et; ez elég jól működik, apró szépséghiba, hogy lassú, mivel habár nem rendereli a nem látható sorokat, de soronként kitesz 1-1 üres div-et, így betöltéskor/lapozáskor mindig 500 div-et kell renderelni :-(

Másodjára a Live Grid-del próbálkoztam; ez nagyon gyors, viszont nincsen hozzá checkbox model :-(

Találkoztatok már hasonló problémával? Nincsen esetleg valami user extension, ami esetleg ezt meg tudná oldani ?

stack 2009.05.17. 10:49:10

LiveGrid-et rendkívül rugalmatlannak tartom, tele számtalan bosszantó hibával, így azt végképp senkinek sem ajánlom semmire.

Szerintem a jelenlegi eszközökkel 500x40 -es táblázatot nem nagyon fogsz tudni megjeleníteni. Inkább gondolkodj azon, hogy miként lehetne módosítani a feladatot. :)

forraikris 2009.05.17. 11:12:35

Én is kezelhetetlennek tartok ekkora adatmennyiséget, mind a böngésző, mind a felhasználó szempontjából :-(

Sajnos akik használni akarják, az asztali "excel-jellegű" megoldásokhoz vannak szokva, és elég nehéz meggyőzni őket arról, hogy az - általuk - választott technológia nem képes erre :-(

Azonban Buffer Grid-del még így is kb. harmad-negyed annyi válaszidő biztosítható, mintha "simán" táblázattal jelennének meg az adatok, szóval az ext js mindenképpen nyerő! :-)

stack 2009.05.17. 11:28:47

Na jó, hát nekem sem merült fel gondolatként, hogy nem az ExtJS lenne a megoldás! :)

Ismerős, az ügyfelek nem nagyon értik, hogy miért kell lapozó, a lapozó + görgő kombinációt meg tényleg sehol máshol nem láthatták... :)

Sajnos még nem volt annyi időm, hogy átnézzem a BufferView-ot, de nekem van egy olyan érzésem, hogy teljesen feleslegesen vannak benne azok az üres sorok. Ha view.mainBody -nak adnánk padding-top-ot és padding-bottom-t, akkor pont ott tartanánk, mint az üres sorokkal.

forraikris 2009.05.17. 11:45:05

Asszem sejtem, mire gondolsz:
- át kellene írni a megfelelő renderer függvényt, hogy a nem látható sorok ne üres div-ként jelenjenek meg, hanem sehogy, illetve, a megjelenő sorok ne csak "feltöltsék" a meglévő div-eket, hanem szúrjanak be újakat
- ezzel párhuzamosan azonban figyelni kell arra, hogy a scrollbar azért megmaradjon; ezt meg is oldja az általad írt padding-os módosítás (és persze onscroll-ra be kell tenni a paddin módosítását)

Erre gondoltál?

stack 2009.05.17. 12:16:10

Igen, valami ilyesmire gondoltam.

- a megjelenő sorok ne csak "feltöltsék" a meglévő div-eket, hanem szúrjanak be újakat

Ebbe nem vagyok biztos, lehetséges, hogy itt ki kellene próbálni több, különböző módszer, mert valószínűleg ez is lassítaná. Azaz továbbra is meg kellene tartani X darab sort, aminek a tartalmát módosítani kellene csak.

prometheus_X 2009.05.19. 15:22:20

forrakis: "Sajnos akik használni akarják, az asztali "excel-jellegű" megoldásokhoz vannak szokva, és elég nehéz meggyőzni őket arról, hogy az - általuk - választott technológia nem képes erre :-("

Szia, ez igen egyszerű javaslat útján megoldható, meg kell kérni az üf.-t, hogy 100Gb-s netet és 6GHz-es gépet vegyenek 16Gb memóriával. Mert technológiai akadálya tényleg nincs, így hát csak egy apró hardverbővítés szükséges. Ha ez drága lenne nekik mégis, akkor feltehetőleg mégis csak van technológiai akadály :)

Egyébként épp grid kezeléssel szívok. Csináltam egy ComboBox variánst ami a DataView helyett a legördülőben gridet jelenít meg, magát a gridet a combo-m configjában a view-nál felül lehet bírálni ahogyan az kultúrált komponenstől elvárható.
Egyre inkább úgy tűnik, hogy ez az "Ön ne csinálja ezt utánam a saját felelősségére" felszólító kategóriás dev, ugyanis kezd vészesen az idegeimre menni pár dolog, ebben a pillanatban épp azon hörgök, hogy a selection model-ek a létező legtrágyább módon lettek megtervezve, ezért kénytelen vagyok if ... instanceof ... megoldást alkalmazni, mivel nincs átfedés a rowselmodel és a cellselmodel közt egyetlen, a kiválasztott elemre vonatkozó (azt lekérdező) metódusok közt sem, miközben a startEditing elvárja a cella megadását is, holott a rowselmodel azt se tudja hogy eszik-e vagy isszák.

Ez lehet hogy csak a saját túlkomplikálásom, de ahogy egyre többet spanolok a grides forráskódokkal fokozatosan látom úgy hogy mint ha nem lenne jellemző rá az ext-es átláthatóság - és akkor nagyon finoman fogalmaztam.

stack 2009.05.19. 23:48:26

Már pontosan nem is emlékszem milyen okból, de én is szembesültem a Cell-Row SM közti különbségekkel... érdemes belenézni a Abstract SM kódjába... az ember sejti, hogy kevés a közös rész, de hogy ennyire! :)

Nem szeretem használni az instanceof -t, általában ilyen esetekben igyekszem inkább a meghívandó függvény létezését vizsgálni.

if (typeof this.selectRow == 'function') {
this.selectRow(....);
} else if (typeof this.select == 'function') {
this.select(....);
} else {
throw 'gebasz van...';
}

Igaz, ez nem minden esetben használható!

prometheus_X 2009.05.22. 04:21:32

Nekem úgy tűnik eddig hogy az instanceof elég megbízható, és elvileg egy OO környezetben "OO-bb" is alkalmazni. Érdemes lenne lemérni, hogy gyorsabb-e esetleg a függvény ellenőrzésnél - én mondjuk csak szemantikailag szeretem jobban :) Másrészt ha A-ban van egy adott függvény, az A leszármazottaiban is lesz, szerencsére a JS-ben nincsenek hirtelen private-tá váló felülbírált metódusok :)

Mondjuk az egy dolog, mennyire felháborító az abstract sm kódja, engem sokkal jobban kiakaszt, hogy mennyi a kusza oda-vissza utalás és a dupla funkcionalitás, és persze emiatt (nyilván ezt elfedendő) a rengeteg dokumentálatlan eljárás, amik közt van néhány általánosan használt is. És persze ezek nyilván olyan kódok, amiket bármelyik következő verzióban különösebb magyarázkodás nélkül kiránthatnak a fenekünk alól.

Szerintem eleve elhibázottan fogták meg a teljes grid-es problémakört. Ami sajnos nem meglepő, mert ez minden vizuális platformban sokszor súlyosan el van hibázva. Jelenleg a grid rugalmassága épp a használhatóságát teszi igazán tönkre, mert rosszul absztraháltak már az elején.

A grid alapegysége a cella. Totális hülyeség hogy a kiválasztó modell határozzon meg alapegységet. Jó ötlet a UI szeparálása - jó lenne, ha nem csak részben valósult volna meg és nem úgy, ahogy. Az adatforrások elérése az Ext legerősebb pontja, ezt JS környezetben az Ext-esnél csak nagyságrendekkel pocsékabbul láttam eddig megvalósítva, ez az egy amibe nem tudok és nincs értelme belekötni. Ha valaha lesz időm rá hogy csináljak grid-es osztályokat, ahhoz saját gridet fogok csinálni egész biztosan.

Az én absztrakcióm nagyjából így fest:
- Az alapegység a cella
- A cellákat cellacsoportok tartalmazzák amelyek pontosan tudják hogy az adott cella a saját rendszerükben hol helyezkedik el, és meghatározhatja az egyes cellainformációk alapértelmezéseit, adott esetben felülbírálhatja azokat a sajátjaival
- Ilyen cellacsoportok a sorok és az oszlopok
- A cellákhoz UI héjak tartoznak, amelyek a cella tulajdonságai alapján vizuálisan reprezentálják a cellát
- Egy cella több UI-t is köthet magához.
- A cellák UI-ei csoportokba rendeződnek
- A cella UI csoportok meghatározhatják és felülbírálhatják a cella UI-ket saját alapértelmezéseikkel
- Cella UI csoportok például: sor csoport, oszlop csoport, váltott színű sor csoport, sorszám oszlop, checkbox oszlop, fejléc sor, stb.
- A cellákhoz akciók rendelhetőek, az egyes akciókhoz cella UI-k és eseménykezelők köthetőek: absztrakt akciók, DD akciók, CRUD akciók, kijelölő akciók, billentyűzet akciók.
- A grid-hez navigációs modell tartozik.
- A navigáció egysége egzakt de meghatározott: sor, oszlop, cella, ... nonfiguratív és így tovább
- A navigációs lépések: vissza, tovább, első, utolsó, belépés az egységbe, belépés egy cellába, kilépés az egységből, kilépés egy cellából, egység kijelölése, egy cella kijelölése (átkötéssel), kijelölés megszüntetése egységen és cellán, aktuális pozíción lévő egységben szereplő cellák lekérése, kijelölt egységek celláinak és kijelölt cellák lekérése
- A grid-hez lekérdező modellek rendelhetőek, amelyek szűrő és egyéb eljárásokat hajtanak végre adott cellacsoportokon
- Az alapértelmezett lekérdező modell a cella l.m. amely minden cellát magában foglal.
- További csoportok definiálhatóak a cellák tulajdonságai alapján: sorok (sor koordinátáik megegyeznek), oszlopok (oszlop koordinátáik megegyeznek), azonos háttérszínűek, azonos adattípust megjelenítőek, azonos kontrol által megjelenítettek, stb.
A grid-hez UI tartozik. Az UI egységbe foglalja az UI csoportokat és meghatározhatja/felülbírálhatja azok alapértelmezéseit.
A grid UI meghatározza a grid megjelenését a felhasználó felé, például fejlécek, láblécek, oldallécek, egyéb extra-megjelenések

Na valahogy így képzelek el egy jól absztrahált grid-et. Oké, ez megvalósítva minimum 30-40 osztály lenne, de kódmennyiséget nézve annyira nem is sok, mert mindegyik atomi funkciókat valósítana meg, és sok lenne az öröklődés is.

stack 2009.05.23. 10:37:54

Átgondolt igénygyűjteménynek néz ki! Becsültél már mellé időt? :)
Egyszer nagyon hiányzott, hogy a Grid-ben nem lehet fa szerkezetet használni, ekkor eljátszottam a gondolattal én is, hogy mi hiányzik ehhez, illetve mit kellene újraírni. Ilyen konkrét igénytervet nem készítettem, csupán addig jutottam, hogy nagyon sok munka lenne. :) Az ExtJS fórumában is sokat beszélgetnek erről, hogy a jelenlegi felépítést nézve nagyon sok minden hiányzik ehhez, pedig kicsit jobb, strukturáltabb felépítéssel, ez már csak egy kis igazítás lenne. Ráadásul még példa is lenne, hogy mit vár az ember egy gridtől: www.treegrid.com/treegrid/www/ és még ebből is sok minden hiányzik. :) Amit leírtál, ahhoz abba mindenképpen jobban beleillik. Mindamellett arra is figyelni kell, hogy egy szimpla táblázatot, ami mondjuk, lekezeli a rowclick-et, azt ugyanolyan könnyen meg tudja valósítani a juzer, mint most. Nem számoltam meg, de általában a sima Grideknél (nem editorGrid) 10-ből 9-szer RowSM-et használok. Valószínűleg a ExtJS-nél is úgy épült ki a jelenlegi rendszer, hogy előbb készült el ez, majd utána épült bele a cellánkénti kiválasztás.
Kíváncsi leszek, hogyha megjelenik majd a RoadMap-on a 3.1 vagy a 4.0-ás verzióhoz tartozó fejlesztések, akkor ott mi fog majd szerepelni ebből. :)

prometheus_X 2009.05.23. 16:03:08

@stack: Tényleg nincs mögöttes szándékom ezzel, de ez tényleg csak egy felületes vázlat volt :) rögtönözve írtam össze a kommentben, korábban én sem foglalkoztam azzal hogy tervezzek egy gridet. Emiatt aztán időbecslést se csináltam még, de a tapasztalat azt mutatja, hogy nekem olyan 2-4 hét lenne a fentit lekódolni. Az elképzelésem nagy előnye szerintem, hogy prekonfigurálható komponenseket is könnyen lehetne belőlük összelegózni, így a populárisabb felhasználási módokra is könnyen lehetne összerakni olyan komponenst, ami gyakorlatilag csak egy config object-ből állnak.
Egyre valószínűbb, hogy az Ext be fog robbanni a szakmába és egyre magasabb elvárásokat támasztanak vele szemben, szerintem hónapokon belül elképzelhető, hogy számottevő igény lesz egy hasonló gridre. Ha belegondolsz, a táblázat az egyik legrégebbi adattárolási logika, az ókorban is ismert volt, az embereknek pedig szüksége van rá egyrészt praktikai, másrészt megszokottsági okok miatt. Szerencsére azt látom, hogy azért az Ext nagyon jó irányba halad és nem hagyják eltrutymósodni. Egy Ext-hez hasonló több éve hiányzik a webes platformról. Amerre haladtak a desktop eszközök és megoldások, arra halad a web is, de a web jócskán 10 évvel le van maradva aminek főleg hardveres és kapacitási okai vannak. Ahogy ezek az elmúlt pár évben kezdenek megszűnni, a web is rákapcsolt. Idővel biztosan meg is fogja előzni az asztali rendszereket.

Sok a leve a mondandómnak, de egy a lényeg, biztosan szánni fogok időt a fent vázolt grid-megoldás lefejlesztésére a következő 2 hónapon belül. Mezei előrelátásból. Elsősorban webalkalmazásokkal szeretnék foglalkozni és így előbb-utóbb elkerülhetetlen lesz egy használható grid lefejlesztése, de a tapasztalat az Ext-tel azt mutatja, hogy az új komponensekre fordítandó idő egyelőre sajnos kristálygömbből se jósolható meg, az pedig komoly kockázatot jelent. Persze ez főleg azért van, mert még mindig szükségem van az API doksi nyálazására - bár úgy, hogy január óta használom a rendszert, nem is rossz hogy azóta lezavartam 3 új controlt, 1 effektelőt, 2 háttér komponenst, 1 patch-et és 1 hotfix-et :) de ez inkább az API-t és az Ext-et dícséri mint engem.

prometheus_X 2009.05.24. 11:09:25

Na, ennyit arról hogy mennyi időm van: http://extjs.com/forum/showthread.php?p=333014#post333014

Eddig legalább a fórumban nem hápogtak hogy gyenge a grid. Asszem elkezdem az előkészítést. Nem szeretném hogy valaki beelőzzön :)

stack 2009.05.24. 11:37:42

Huh… neked eszméletlen sok szabadidőd/kapacitásod lehet. :) Ha elkezded a fejlesztést, akkor mindenképpen számolj be a részeredményekről (is). Kíváncsivá tettél. Szerintem alábecsülöd az időd, vagyis én nem merném ezt ilyen határidővel bevállalni. :)

Saját komponens gyártásánál én mindig mérlegelek, mennyi az esély annak, hogy a közeljövőben valaki elkészíti helyettem vagy sem. :) Nem lustaság, inkább racionalitás. És míg az Ext.grid-et valószínűleg javítgatják a support team tagjai, addig például egy raktári alaprajztervezőt a fennért nem csinálnak. :) Az UML szerkesztőt várom nagyon, de a kollégák már nagyon nyaggatnak, hogy mindent a felületről kellene szerkeszteni, így pl. a törzsadatok szerkezetét is, így valószínű hamarabb állnék neki annak, mint a Grid-nek.

prometheus_X 2009.05.24. 23:00:08

@stack: Frászt, a szabadidőm mínuszos :D Én még nem olvastam arról hogy tervezne a support új grid-et, ellenben igény egyre inkább van rá. A javítgatásával sajnos nem lesz jobb. Ugyebár !(build(sz@r) instanceof vár) :D.

Amiket eddig fejlesztettem, azok mind egyedileg kellettek. Nem állítom hogy nem lehetett volna egyáltalán sehogy se megoldani ezeket a dolgokat meglévő elemekből. Én viszont azt szoktam mérlegelni, hogy szeretnék-e sok kört futni debug-olással :)

Teljesen változó hogy mikor mennyi időt fogok a grid-re szánni. De minden nap minimum 1 órát. A lényeg hogy ha apránként is, de haladjak vele. Nem ilyesztő annyira.
A bug ami miatt a hidden/collapsed panelek alatti cuccok széthullanak megjelenítés után, sokkal ijesztőbb, de ott se nagyon van választásom, meg kellett patch-elnem a support patch-ét, rá ment vagy 5 órám :S Most pár perce kipakoltam a patch-et a fórumra és várok, hátha nem csak nálam működik :D

Visszatérve a grid-re... valszleg fellövök majd annak is egy topicot a 3.0 alá, már persze amikor már lesz mire. Ma már foglalkoztam vele egy órát amíg a gyereket pesztráltam a játszótéren :) azt mérlegeltem, hogy a cellák vajon Field-ből vagy BoxComponent-ből származzanak-e, végül az utóbbi mellett döntöttem annyi kikötéssel, hogy lesz mód hozzárendelni hiddenfield-et. Ez azért fontos, mert szeretném ha normál módon is posztolható lenne a grid. Meg mert hax és nem tart semmiből megoldani :)

stack 2009.05.25. 23:46:17

@prometheus_X: ha majd lesz valami, akkor itt is megmutathatnád! :)

Szerintem két fontos dologra kellene ügyelned, az egyik a rugalmasság (ugye ez a fő cél:) és a sebesség. Annak fényében jutott ez eszembe, hogy biztos jó ötlet minden cellát az Observable-ből örököltetni? Az persze nem rossz, ha külön kezeled őket, de lehet akár a Toolbar.Item-ekhez hasonlóan direkt csak az ő egyszerű funkcionalitásuknak megfelelő osztályt elkészíteni.

(zárójelben utálom is a Toolbar-t emiatt, de egy gridben biztos nem kell nekem majd a findBy és hasonló függvények használata egy cella megkeresésére:)

prometheus_X 2009.05.26. 14:57:02

@stack: Olyasmi megoldásra gondoltam mint a fent említettek, azaz mindig csak a keretben látszó cellák kerülnek megjelenítésre. Máskülönben egy normál grid is felzabálná a memóriát, a renderelési sebességről nem is beszélve. Elvégre egy éppen a viewport-on kívül eső cellával mit kezdhet a felhasználó? - semmit. Forrás oldalon attól még elérhetővé lehet tenni a cellákat. Hogy kiküszöböljem a "türelmetlen user" szindrómát, lesz olyan config kapcsoló, ami ha true, akkor nem 1, hanem 3 viewport-nyi cellát renderel le, így a leggyakoribb felhasználói (fel, le, pgup, pgdn) műveletek gyorsak lesznek. Egy másik kapcsolóval pedig be lehet állítani, hogy ugyanezt az X tengelyen is így csinálja. Hogy az erőművet használók felhasználói élményhez való joga ne sérüljön, lesz mód a pufferelés kikapcsolására, sőt, ezeket a beállításokat lehetőség lesz a UI-n is elérni (a hogyanját majd kitalálom később).

prometheus_X 2009.05.26. 14:59:00

@stack: Toolbar ügyben használd a 3-as Ext-ét sztem, abban már Container-ből származik és van benne find*().

stack 2009.05.26. 19:15:09

@prometheus_X: én türelmes ember vagyok, megvárom a stabil verziót! :)

Az, hogy nem jeleníted meg, amikor nincs rá szükség, meg, hogy miből származik szerintem nincs összefüggésben. Egy BoxComponent-nek nagyon sok tulajdonsága, eseménye van, ami egy cellánál értelmetlen... szerintem. :)

prometheus_X 2009.05.26. 20:38:58

@stack: Oké, picit megalomán vagyok :) Még gondolkodom rajta hogy hogyan oldjam meg ezt a problémát. Előferdülhet hogy az első verzióban nem fogok vele foglalkozni, látatlanban nehéz megmondani, hogy mennyi problémát okozna - pontosabban ilyen jellegű tapasztalatom még nincs az Ext-tel.

prometheus_X 2009.05.26. 22:39:15

Kitaláltam a megoldást: a cella maga Observable-ből fog származni, az UI csak egy property-je lesz, ami a pufferelési beállításoknak megfelelően fog létrejönni/felszabadulni. Ez az UI egy wrapper lesz, Container-ből fog származni, hiszen a fenti vázlatban említettem, hogy egy cellához több UI is tartozhat. Az UI wrapperen keresztül lehet majd meghatározni, hogy a felhasználó melyik UI-t lássa. A gördülékeny használat kedvéért lesznek prekonfigolt UI wrapperek, pl. csak megjelenítésre illetve megjelenítésre és szerkesztésre.

Remélem így eléggé perverz már :)

stack 2009.05.28. 09:16:38

@prometheus_X: Na... és mikor lehet majd megnézni valamit a készülő műből? :)

carstep 2009.05.28. 18:29:17

@prmetheus_x

ha gondolod en is besegitek bizonyos reszekbe, ha van ra igeny. En a 2.0.2-s verziot hasznalom, esetleg arra is fejleszthetnenk, nem hiszem, hogy az alapok nagyon valtoztak volna! Meg nem volt idom megvizslatni 3-as verziot. Nem tul mely a javascript tudasom, te tesztelesre szivesen jelentkezem!

-cs-
Sanyi

prometheus_X 2009.05.29. 00:23:32

@carstep: Szia, köszi az ajánlatot, segítségből sosem elég :) A tapasztalataim azt mutatják hogy a 2.x-hez képest gigászi mennyiségű bug-ot javítottak a 3-asban, ettől persze még nem fogytak el azok se :) de ha másért nem, ezért biztosan megéri váltani. Az RC1.1 relatíve stabil, de elnézve a bejelentett bugokat, érdemes lesz megvárni a stabil release-t. Nekem annyi mázlim van, hogy a 3.0-át már az Ext Core alatt el kezdtem vizsgálni, és amint kijött az első RC, húztam egy bátrat és váltottam, így a fontosabb patch-eket folyamatosan tudom beszerezni - ami sajnos amúgy eléggé követhetetlenül van vezetve.
Valószínűleg a stabil 3-as kivágja a fát majd a 2-es alól, de amíg az nem jön ki, lehet hogy érdemes lesz 2.x-re is portolni. Ez eddig azért nem merült fel, mert nekem nincs igazán kimondottan 2-es fejlesztésem, ellenben a 3-ason nekem most elég sok minden múlik. Másrészt pont emiatt a 2-est nem ismerem, csak annyit tudok róla, hogy vannak sajátosságai (a fenti problémát, amit stack is említett a Toolbar-ról, azt konkrétan pont ismertem mert én is belefutottam és k.anyáztam is miatta rendesen).

Újabb adalék a GridPanel problémákhoz: 2 óra doksi turkászás után se jöttem rá, hogy a fenébe lehet beállítani az egyes sorok magasságát. Pár beállítást kipróbáltam de egyik se vált be, végül hagytam a fenébe.

@stack: @carstep: a jövőhét folyamán fogok kreálni egy google code SVN repo-t, az elérhetőségét azonnal meg fogom adni egy kommentben.

Még egyszer köszi mindenkinek :)

prometheus_X 2009.05.29. 00:44:37

A mai termés: a cella koordinátáinak a kezelését függetleníteni fogom a celláktól, a koordinátákat külön osztályok fogják kezelni :) azt, hogy mi értelme lenne egy 1D-s gridnek, vagy hogy ki lesz az első perverz állat aki 3D-s grid-et akar majd használni, még nem tudom, de ne érje szó a ház elejét :)
Szóval lesz egy osztály, aminek egy példánya fog a gridhez tartozni, azon keresztül lesznek azonosíthatóak a cellák, ez az osztály Ext.util.Collection-ből fog származni. Egy másik primitív osztály gyakorlatilag csak a cella koordinátáit fogja tartalmazni.

És akkor most el is kezdem szerintem összelegózni a dolgot UML-ben :)... kezdeném ha az Umbrello-m nem szállna el minden kattintásra SIGSEGV-vel :S akkor viszont kódolok :)

stack 2009.05.29. 09:30:58

Én is azt a nézetett osztanám, hogyha ma elkezd valaki egy nagyobb fejlesztést, akkor azt már az új eszközzel készítse... max. ha nagyon kell, akkor a 2.0.2-höz külön legyen egy patch.

A három dimenziós grid-del még azért várjál, mert ahhoz olyan Store is kellene. :)
Az egy dimenziósat meg úgy hívják, hogy Label, EditorGrid esetén meg Field-nek :D

ui: Szerintem a GridPanel-nél nincsen olyan, hogy sorok magassága. Ha beleteszel egy 50px magas képet, akkor annak megfelelő magasságú lesz. A 21px magasság csak az alapértelmezett, ami néhány css szabály miatt van.

carstep 2009.05.29. 10:36:28

@stack: akartam en is valaszolni erre, feltetelezem CSS beallitassal erik el, hogy a tartalomnak megfelelo magassagu legyen a cella

-cs-
Sanyi

carstep 2009.05.29. 10:38:22

@carstep: mivel amugy is (2.0.2) eseten tablazatot hasznalnak, amelynek cellai eleve igy viselkednek, ezert meg css sem kell hozza :-)

-cs-
Sanyi

carstep 2009.05.29. 10:39:57

@prometheus_X: ki tudja, a 3D grid a canvas, vml eseten nem nehez abrazolni (mar aki tudja ezeket), ugyhogy akar meg hasznos is lehet :-)

-cs-
Sanyi

prometheus_X 2009.05.30. 11:46:02

@stack: Ha csak egy koordináta tengely adott (1D), abból még lehet lista vagy egy sornyi cella egymásmellett :)) amiről Te beszélsz, az a 0D, és olyat is lehet majd csinálni :D
A 3D-s gridnek perpill reálisan egyetlen egy értelmét látom, ami az Ext vonatkozásában is érdekes lehet: ha a grid adatait mondjuk 3D flash chart-ban akarja valaki megjeleníteni.
Hm... meg kell oldanom a tengelynézetek váltását, jajj de jó :)

@carstep: Canvas ügyben kijött egy egész érdekes fejlesztés, a Cufón, amivel canvas-t és VML-t használva lehet egyedi SVG fontokat megjeleníteni egy oldalon. Kezdetleges mint a kőbalta, de kezdeményezésnek előremutató. Persze ez nem Ext vonatkozású dolog, de JS.

prometheus_X 2009.05.30. 12:02:37

@stack: Hogy a Store csak 2D-t kezel, az engem nem fog visszariasztani :) Köztes megoldásként lesz egy extra adatelérő osztály is, aminek meg lehet határozni, hogy melyik adatsor köthető melyik tengelyhez, ideértve metaadatként a sorokat és az oszlopokat is. Így tfh egy 3D-s grid ábrázolásánál x=metaoszlop, y=metasor, z=id. Azzal pedig, hogy az adatok a megfelelő formában legyenek küldve, majd szív az, akinek kevés a 2D.

carstep 2009.06.03. 17:17:36

@prometheus_X: feltettem en is az umbrello bar nekem elegge sokszor kiakad / elszall :-(. Arra gondoltam mi lenne, ha ext-core ral fejlesztenenk a Grid-et, ezzel liszenszelesi problemakat is konnyebben lehetne kezelni, ha opensource maradna a projekt. Termesztesen, akkor mindent meg kellene melle irni az adatkezelest es a vizualis megjelenitest is :-(

apropo, sikerult a projektet svn-re vagy git-re vhova feltenned?

-cs-
Sanyi

stack 2009.06.05. 23:09:11

@carstep: Persze ebben a témában én csak külső szemlélődöként szólok bele, de a Core használata egy ilyen projektnél nagyon problémás lenne. Osztályok, amik elsőre eszembe jutnak, és egy ilyen összetett komponensnél használni kell: Store, DataView, KeyMap, DragDrop, StateManager... ezek mind hiányoznak a Core-ból.

tgoldea · http://www.joobba.hu 2009.12.09. 21:43:57

Sziasztok, régóta olvasgatom ezt a fórumot, és most úgy alakult, hogy konkrét projektekhez szükségünk lenne még senior EXT JS fejlesztőre. A feladat üzleti intelligencia alkalmazások fejlesztése kis és középvállalati körben. Elvárások: EXT JS 3.0 core, PHP, JAVA, Postgre Sql/Oracle, tárolt eljárások, script nyelvek ismerete, LDAP, Active directory. Előny: Hibernate, Exchange szinkronizációs ismeretek. Jelentkezni a goldea@joobba.hu címen lehet. Alapvetően távmunkáról lenne szó és konkrét projektre szól. Üdv: Ifj. Goldea Tamás JOOBBA BUSINESS INTELLIGENCE

LuxiMFP 2010.09.20. 08:24:49

Szia,

Köszi, pont egy ilyen megoldást kerestem!

Annyi kérdésem volna, hogy nálam az első megjelenésnél nem tudja kiszámolni a limit-et, mert a getHeight() 0-val tér vissza.

Beleraktam még egy ilyet is:
cmp.on('afterrender', cmp.fixPageSize, cmp, { delay: 10 });

de a helyzet ugyanaz. Ami érdekes viszont, hogy ha teszek egy breakpoint-ot a fixPageSize() elejére, és csak gyorsán végigugrálok rajtuk, akkor már van értéke a getHeight()-nek.

Elnézést ha benéztem valamit, eléggé kezdő vagyok még az Ext.JS témájában (eddig coolite-ot használtam, de most már inkább közvetlenül a javascript-ben dolgozok)

Köszönöm, Luxi

stack 2010.09.22. 18:39:42

Szia, ha mutatsz teljes kódot, akkor ránéznék, így hirtelen nem látom, hogy miért nem működik. A resize eseménynek le kellene futni akkor is, amikor van méret.

ExtJS blog, mi ez?

Az ExtJS egy JavaScript keretrendszer, melyet a blog írója elfogultan a legjobbnak tart, és ez a blog olyan apróságok gyűjteménye, melyek ExtJS használata közben felmerültek, eszébe jutottak...

Címkék

ajax (4) alignto (1) állás (3) analytics (1) anchorto (1) android (4) animate (2) array (9) auto (1) back button (1) beautifier (1) beforeevent (1) benchmark (1) blur (1) budapest.js (1) button (1) canvas (1) capture (1) case sensitive (1) center (1) change (1) cikkajánló (1) class (2) closure compiler (1) collapse (1) combobox (3) comment (1) console.log (2) contextmenu (2) core (2) count (1) css (15) csv (1) dataview (1) date (4) datefield (3) datepicker (1) debug (1) doksi (1) dragdrop (1) easing (1) eclipse (1) editor (1) element (5) error (5) eval (2) event (1) fejtörő (1) field (2) fieldset (1) filter (1) firefox (4) firefox extension (2) focus (3) fonts (1) fun (1) function (1) google (2) google chrome (1) grayscale (1) grid (4) group contact (1) header (3) height (2) hidden (1) hirek (2) history (1) htaccess (1) html5 (2) htmleditor (2) https (1) icon (3) id (2) ie (2) ie6 (1) ie9 (1) iframe (3) image (2) indexof (1) javascript (1) jquery (2) jslint (2) jsmin (1) json (7) keymap (1) kipróbálom (2) könyvajánló (2) label (1) layout (1) lint (1) log (1) loop (1) magyar (2) mandelbrot (1) mask (1) math (1) maxlength (1) mistake (1) mysql (5) napi szívás (16) nem extjs (12) node (1) nth child (1) number (1) off (5) offline (1) operator (1) override (20) pagesize (1) paging (2) panel (2) php (7) picker (1) plugin (3) pozicionálás (2) preload (1) print (1) propertygrid (1) pseudo (3) readonly (2) record (1) regexp (1) replace (1) resizable (1) rotate (1) round (1) scale (1) sencha touch (2) server (1) shuffle (1) slider (1) sort (3) sortable (1) store (2) string (7) sum (1) tabchange (1) tabpanel (1) tab key (2) tdd (1) template (1) textarea (2) textfield (1) textitem (1) theme (2) throw (1) timer (1) timestamp (1) title (2) toggle (1) toolbar (6) tools (1) total count (1) transparent (1) tree (1) treenode (1) trigger (1) truncate (1) try (1) ucfirst (1) undefined (2) unique (1) unload (1) urlencode (1) utf8 (2) verzió (1) video (1) viewer (1) viewport (2) visible (2) vtype (1) window (2) xtype (1) zindex (2)

Extjs.blog.hu - RSS

Kérdés?

süti beállítások módosítása