1. #11
    Sencha User galdaka's Avatar
    Join Date
    Mar 2007
    Location
    Spain
    Posts
    1,166
    Vote Rating
    -1
    galdaka is an unknown quantity at this point

      0  

    Default


    Not work in IE6!!

    Thanks for your time!!

  2. #12
    Sencha User ThorstenSuckow's Avatar
    Join Date
    Sep 2007
    Location
    Aachen, Germany
    Posts
    597
    Vote Rating
    2
    ThorstenSuckow is on a distinguished road

      0  

    Default


    Thanks @all for your feedback so far...

    Quote Originally Posted by KimH View Post
    However....
    - Doesn't work in IE6 (the column headers aren't visible, and no data).
    - In Firefox it seems that the call to data-proxy.php returns JSON data or error (see below).
    I haven't tested this on IE6. Is the grid component even supposed to work with IE6? Can you send me a screenshot or an error description of the Firefox problem?


    Quote Originally Posted by KimH View Post
    Suggestions:
    - Could you make sure that data-proxy.php only returns the first 13 rows of data (or the number of rows that is visible in the grid)?
    Well, you can adjust the buffer size to only return this specific number of records. However, this means that the store will request new data every time the user scrolls one row up/down AND you have to make sure that your grid never shows more than 13 rows at once, which will totally fail it is resizable (sitting in a resizable Ext.Window, for example). Why would you want this behavior? Is there any use case?

    Quote Originally Posted by KimH View Post
    - If I only scroll one row down it should return the next 13 rows of data (as I'm probably going to advance one row more.... and more....).
    As of now, the store holds a specific range of data. If you scroll down to a row that's not within this range, a new request for fresh data is being sent.

    Quote Originally Posted by KimH View Post
    - It looks like it is retrieving data even though it should have it cached? If I go from the top to the bottom and back then I get the reloading mask. Could you configure it to keep data in the browser OR reload every time?
    You get the reloading mask because when you were scrolling down the component tried to load the data that is associated with the current row index. When scrolling up, the store most likely has the data for the very bottom of the component; but since the row index changed, new data has to be requested. Additionally, the view does indeed pre-buffer data to improve scrolling behavior.
    There is no way to predict the scroll behavior of a user. Thus, a reload of data is neccessary everytime the row index changes AND the if this row index is not within the range of currently buffered records.
    Sure, you could fill up the store with all the records a user once has scrolled through. But then again, when having a large amount of data, browser performance will decrease dramatically.

    Quote Originally Posted by KimH View Post
    Questions:
    Which license is this released under? The same as ExtJS?
    It's the same as ExtJS: LGPL.

  3. #13
    Sencha User
    Join Date
    Oct 2007
    Location
    Berlin, Germany
    Posts
    889
    Vote Rating
    9
    wm003 will become famous soon enough

      0  

    Default


    Quote Originally Posted by MindPatterns View Post
    There is no way to predict the scroll behavior of a user. Thus, a reload of data is neccessary everytime the row index changes AND the if this row index is not within the range of currently buffered records.
    Sure, you could fill up the store with all the records a user once has scrolled through. But then again, when having a large amount of data, browser performance will decrease dramatically.
    Well, you dont really need to rebuild all data, you have already in your store loaded. What about just rendering the visible area as usual, but if reloading needs to be neccessary your code could look up into the store, if the desired data has already been loaded before. This way, you will still do a "loading"-part, but not over XHR, but by "loading" from the already present javascript store. I guess this would increase the data access and thus the rendering of the new lines very much, because you dont need to wait for some XHR response and i also guess this won't make it neccessary to display this "loading" layer and makes the overall usage much more smoother and comfortable.

  4. #14
    Sencha User ThorstenSuckow's Avatar
    Join Date
    Sep 2007
    Location
    Aachen, Germany
    Posts
    597
    Vote Rating
    2
    ThorstenSuckow is on a distinguished road

      0  

    Default


    Quote Originally Posted by wm003 View Post
    Really? Well, you dont really need to rebuild all data, you have already in your store loaded. What about just rendering the visible area as usual but if reloading needs to be neccessary your code could look up into the store, if the desired data has already been loaded before. This way, you will still do a "loading"-part, but not over XHR, but by "loading" from the already present javascript store. I guess this would increase the data access and thus the rendering of the new lines very much, because you dont need to wait for some XHR response and i also guess this won't make it neccessary to display this "loading" layer and makes the overall usage much more smoother and comfortable.
    The problem here is browser performance. If the user scrolls through the grid and the store gets accumulated with all the loaded records (of a 10.000 records store, for example), the browser will request large chunks of memory. Additionally, looking up records in the store will become real slow.
    I see your point in letting the user decide how many records he want to have in the store. However, you can still adjust the bufferSize property to the number of records your underlying data model contains. This will load up all records in the beginning, but shouldn't send out any request for new data while scrolling.

  5. #15
    Sencha User krycek's Avatar
    Join Date
    Jun 2007
    Posts
    96
    Vote Rating
    0
    krycek is on a distinguished road

      0  

    Default


    MindPatterns, very good extension, congratulations. But what if I want to keep the paging and also want to use your livegrid?

    Ex.: showing records from 20 to 30 means on a paging way that users would be in the second page, right? So users could navigate between the records entering a page number to go to or scrolling down/up the table. So when the user entered page 5 the grid would scroll down and show records 50-60.

    Could it be done?

  6. #16
    Sencha User ThorstenSuckow's Avatar
    Join Date
    Sep 2007
    Location
    Aachen, Germany
    Posts
    597
    Vote Rating
    2
    ThorstenSuckow is on a distinguished road

      0  

    Default


    Quote Originally Posted by krycek View Post
    MindPatterns, very good extension, congratulations. But what if I want to keep the paging and also want to use your livegrid?

    Ex.: showing records from 20 to 30 means on a paging way that users would be in the second page, right? So users could navigate between the records entering a page number to go to or scrolling down/up the table. So when the user entered page 5 the grid would scroll down and show records 50-60.

    Could it be done?
    Sure, although calculating the row index associated with the page you want to go to is totally up to you, everything you need is to call the method ensureVisible(rowIndex, colIndex, horScroll) from the BufferedGridView component.
    This method will handle changing the scroll position and reloading data, if needed.

  7. #17
    Sencha User
    Join Date
    Oct 2007
    Location
    Berlin, Germany
    Posts
    889
    Vote Rating
    9
    wm003 will become famous soon enough

      0  

    Default


    Quote Originally Posted by MindPatterns View Post
    The problem here is browser performance. If the user scrolls through the grid and the store gets accumulated with all the loaded records (of a 10.000 records store, for example), the browser will request large chunks of memory. Additionally, looking up records in the store will become real slow.
    Maybe you take a look at http://www.treegrid.com/TreeGrid5_0/Html/Example1M.html

    Here he manages to display about 1000000 records with only loading data, if it hasnt been loaded earlier. When you scroll down a few pages and then up again ( to the records that were shown earlier) the script is _not_ reloading but immediatly displaying the earlier loaded data. So it seems, there must be some possibility to solve this problem.

    Maybe if you hold 2 separate stores. One small for the visible grid which only holds the displayed data and one which holds every loaded data and grows by every XHR request for lookup of already available data? Just a fast suggestion. So the original Ext-Grid routine always has just a few "visible" data, but the local script datastore grows to have the data faster than over xhr.

  8. #18
    Sencha User ThorstenSuckow's Avatar
    Join Date
    Sep 2007
    Location
    Aachen, Germany
    Posts
    597
    Vote Rating
    2
    ThorstenSuckow is on a distinguished road

      0  

    Default


    Quote Originally Posted by wm003 View Post
    When you scroll down a few pages and then up again ( to the records that were shown earlier) the script is _not_ reloading but immediatly displaying the earlier loaded data. So it seems, there must be some possibility to solve this problem.
    Do not get me wrong, it's totally possible to add the loaded records to the store while they were buffered, so the don't have to be reloaded.
    The only problem is the waste of memory - in the given example the memory usage for IE7 raised from 40 MB up to 130 MB.

    The default behavior of my component will not support adding those records to the store while buffered, since I have no clue about the memory size of my clients' computers, and I do not want my component to cause a "page file limit reached" message

    As for now, simply adjust the bufferSize to the total length of data available in your db table.
    I might add a configuration option which keeps once-loaded records in the store. However, this depends on the overall need of this feature and the simplicity of implementing it.

  9. #19
    Sencha User
    Join Date
    Oct 2007
    Location
    Berlin, Germany
    Posts
    889
    Vote Rating
    9
    wm003 will become famous soon enough

      0  

    Default


    Quote Originally Posted by MindPatterns View Post
    in the given example the memory usage for IE7 raised from 40 MB up to 130 MB.

    I do not want my component to cause a "page file limit reached" message
    Agreed

    Maybe some of the Ext Core Developers know some performance trick to prevent memoryincreasing? (independant of the gridview, maybe they had some similar problems while developing other parts of ext) If i understood correctly, its not performance (javascript gets slower), but uncontrollable memory-wasting (i dont see a reason, why IE would increase 90 MB, if the raw data, that should be buffered, will most likely never reach such an amount. So it seems to be a (IE specific?) Problem regardless of the used ext-widget?

    Hopefully they had similar problems solved earlier and can help out here..(?)

    btw. i'll test your widget on IE6 tomorrow.

    keep up the good work,mindpatterns, you are on the right way, i think!

  10. #20
    Sencha User ThorstenSuckow's Avatar
    Join Date
    Sep 2007
    Location
    Aachen, Germany
    Posts
    597
    Vote Rating
    2
    ThorstenSuckow is on a distinguished road

      0  

    Default


    Quote Originally Posted by wm003 View Post
    Maybe some of the Ext Core Developers know some performance trick to prevent memoryincreasing? (independant of the gridview, maybe they had some similar problems while developing other parts of ext) If i understood correctly, its not performance (javascript gets slower), but uncontrollable memory-wasting (i dont see a reason, why IE would increase 90 MB, if the raw data, that should be buffered, will most likely never reach such an amount. So it seems to be a (IE specific?) Problem regardless of the used ext-widget?
    The memory usage is caused by the records (Ext.data.Record) that get pushed into the store. Think about having a record that has 10 different fields, and each field holds a minimum of 50 bytes of data. For each row, that makes 500 bytes, 2 rows would make something around 1kB. Multiply that by the number of records you want to keep in the store at once. I do not know how IE and all the other browsers handle intern storage of data in arrays, but from my experience I'd say that for storing 1 kB of data, the browsers reserve much more memory. The more data to be held in the heap, the more memory your browser will request.

    Quote Originally Posted by wm003 View Post
    btw. i'll test your widget on IE6 tomorrow.

    keep up the good work,mindpatterns, you are on the right way, i think!
    Thanks, I hope my work is usefull for you guys out there.

Thread Participants: 248

  1. JeffHowden (1 Post)
  2. Animal (4 Posts)
  3. rodiniz (1 Post)
  4. galdaka (2 Posts)
  5. mdissel (1 Post)
  6. Wolfgang (1 Post)
  7. zzo (2 Posts)
  8. Frank (1 Post)
  9. herve (2 Posts)
  10. ericd (2 Posts)
  11. RWaters (5 Posts)
  12. Digital God (1 Post)
  13. Dumbledore (11 Posts)
  14. KimH (1 Post)
  15. pjordan (1 Post)
  16. cpantel (1 Post)
  17. mystix (3 Posts)
  18. wanclark (1 Post)
  19. MD (3 Posts)
  20. drew (1 Post)
  21. jheid (15 Posts)
  22. tsprague (1 Post)
  23. Confused (2 Posts)
  24. thesilentman (1 Post)
  25. andreas.linde (1 Post)
  26. violinista (1 Post)
  27. redxiii (1 Post)
  28. akannu (1 Post)
  29. theo (1 Post)
  30. Troy Wolf (3 Posts)
  31. chh (4 Posts)
  32. Phenothiasine (1 Post)
  33. danh2000 (1 Post)
  34. tobiu (1 Post)
  35. badgerd (1 Post)
  36. mlarese (1 Post)
  37. pluesch0r (1 Post)
  38. krycek (1 Post)
  39. gtaylor (4 Posts)
  40. ftftft (1 Post)
  41. hallikpapa (7 Posts)
  42. tech-nova (1 Post)
  43. provagino (1 Post)
  44. mjlecomte (2 Posts)
  45. iancmcc (1 Post)
  46. andrei.neculau (7 Posts)
  47. zieli1 (1 Post)
  48. meteorbites (1 Post)
  49. brookd (3 Posts)
  50. alexpetri (1 Post)
  51. urskipfer (1 Post)
  52. JEBriggs (1 Post)
  53. magunes117 (6 Posts)
  54. shiweiwei97 (3 Posts)
  55. vpell (1 Post)
  56. gelleneu (4 Posts)
  57. ohhowihateie (2 Posts)
  58. Andrewd2 (1 Post)
  59. Jacob (1 Post)
  60. cherbert (2 Posts)
  61. DragonFist (1 Post)
  62. marcoas (1 Post)
  63. Shmoo (1 Post)
  64. GraemeBryce (1 Post)
  65. w011117 (1 Post)
  66. luxxxian (1 Post)
  67. loverofdream (1 Post)
  68. lvanderree (1 Post)
  69. robw (1 Post)
  70. SeaSharp (1 Post)
  71. xpressive (1 Post)
  72. jeremia (1 Post)
  73. wm003 (21 Posts)
  74. miti (1 Post)
  75. sfrancolla (1 Post)
  76. Blob (1 Post)
  77. WoLpH (5 Posts)
  78. khatuido (3 Posts)
  79. zacware (3 Posts)
  80. mepfuso (2 Posts)
  81. wasp (1 Post)
  82. sharpguy (1 Post)
  83. stevets (1 Post)
  84. fred (1 Post)
  85. eliasp (3 Posts)
  86. h0tzenpl0tz (1 Post)
  87. tonedeaf (1 Post)
  88. Zolcsi (3 Posts)
  89. dearsina (1 Post)
  90. efattal (3 Posts)
  91. franck34 (3 Posts)
  92. tyr (1 Post)
  93. cybertaz (1 Post)
  94. zergworld (8 Posts)
  95. sekundek (1 Post)
  96. cs_alpha (3 Posts)
  97. Sultanalifezar (3 Posts)
  98. emily (7 Posts)
  99. jwendt@iscinternational.com (1 Post)
  100. sinma (1 Post)
  101. ItsMee (3 Posts)
  102. Nic (1 Post)
  103. sksoft (4 Posts)
  104. mjhaston (1 Post)
  105. mattb (4 Posts)
  106. jenner (1 Post)
  107. 2le (1 Post)
  108. bluefeet (1 Post)
  109. PremiereGlobal (2 Posts)
  110. rtozati (1 Post)
  111. KirkOlson (4 Posts)
  112. False Maria (1 Post)
  113. jbd007 (5 Posts)
  114. c.barca (1 Post)
  115. nctag (34 Posts)
  116. kfironit123 (1 Post)
  117. Emt (1 Post)
  118. ub3rn00b (12 Posts)
  119. Ballsacian1 (1 Post)
  120. mprice (1 Post)
  121. srikanthnukala (2 Posts)
  122. Mots (2 Posts)
  123. yhwh (1 Post)
  124. el777 (1 Post)
  125. JoomlaMan (1 Post)
  126. sanjivank (1 Post)
  127. sdetweil (1 Post)
  128. Snakehit (1 Post)
  129. msynovic (2 Posts)
  130. Snuyt (1 Post)
  131. as (2 Posts)
  132. pkmiec (2 Posts)
  133. epoks (2 Posts)
  134. NoahK17 (1 Post)
  135. praneeth528 (2 Posts)
  136. bemn (1 Post)
  137. Remy (1 Post)
  138. Daniel_Brazil_Campinas (1 Post)
  139. freddyk (4 Posts)
  140. dshorthouse (1 Post)
  141. dahman7 (1 Post)
  142. Canard64 (1 Post)
  143. dkuz (2 Posts)
  144. xsuniwov (1 Post)
  145. neha.chopra (1 Post)
  146. Eric24 (2 Posts)
  147. Mandeep (2 Posts)
  148. ttbgwt (6 Posts)
  149. suzan (1 Post)
  150. tenthcup (5 Posts)
  151. excelsis (5 Posts)
  152. DaveBrewster (6 Posts)
  153. rusty124 (1 Post)
  154. bcmatz (3 Posts)
  155. bjcullinan (1 Post)
  156. sstratton (4 Posts)
  157. Scorpie (1 Post)
  158. supercharge2 (3 Posts)
  159. Bing Qiao (6 Posts)
  160. tmaung (1 Post)
  161. xenon (4 Posts)
  162. sureaintme (5 Posts)
  163. animeshsingh (2 Posts)
  164. NicoP (29 Posts)
  165. cyfl (2 Posts)
  166. simplessus (1 Post)
  167. imnphd (1 Post)
  168. mono blaine (5 Posts)
  169. Kango_V (5 Posts)
  170. cain06 (1 Post)
  171. charak (2 Posts)
  172. vayumahesh (1 Post)
  173. Gabor Turi (1 Post)
  174. daeghran (2 Posts)
  175. maceido (5 Posts)
  176. sgoswami (1 Post)
  177. rubaiz (1 Post)
  178. Jabe (1 Post)
  179. ecarrenho (1 Post)
  180. mpereira (1 Post)
  181. changhua (4 Posts)
  182. alexw23 (1 Post)
  183. fxmisticat (5 Posts)
  184. extjssiva (1 Post)
  185. f1xxx3r (1 Post)
  186. SimoAmi (1 Post)
  187. aj3423 (1 Post)
  188. kkothari (2 Posts)
  189. jmariani (28 Posts)
  190. ibet (3 Posts)
  191. SunWuKung (1 Post)
  192. micgala (2 Posts)
  193. inptisto (1 Post)
  194. TheColonel (1 Post)
  195. cdeguzman (1 Post)
  196. ektanit (6 Posts)
  197. James Wang (1 Post)
  198. PCBingoB (1 Post)
  199. flylaputa (1 Post)
  200. MacSimon (1 Post)
  201. pibree (2 Posts)
  202. Markus (1 Post)
  203. aleister999 (2 Posts)
  204. adamli (2 Posts)
  205. jmaisel (4 Posts)
  206. pdugas (1 Post)
  207. plaak (1 Post)
  208. coriolis (2 Posts)
  209. weazil (4 Posts)
  210. fwiethof (1 Post)
  211. meroy (19 Posts)
  212. lxf1101 (2 Posts)
  213. stephen.friedrich (3 Posts)
  214. vinepod (1 Post)
  215. yuriy (2 Posts)
  216. completej (1 Post)
  217. dan_jf (1 Post)
  218. harel (2 Posts)
  219. veenvliet.morion (2 Posts)
  220. yura620310 (1 Post)
  221. barncat (1 Post)
  222. DmitrySistor (2 Posts)
  223. pclovec (3 Posts)
  224. Ranma13 (1 Post)
  225. swang (4 Posts)
  226. calugaru.cristian (5 Posts)
  227. mohan_b (1 Post)
  228. karlsnyder0 (2 Posts)
  229. JimmyInMD (2 Posts)
  230. tolitius (1 Post)
  231. a.labeau (2 Posts)
  232. benjixx (1 Post)
  233. psm1963 (1 Post)
  234. sosy (1 Post)
  235. nosferatum (10 Posts)
  236. daddie888 (1 Post)
  237. ixvivxi (1 Post)
  238. dp814082 (1 Post)
  239. nickelj (4 Posts)
  240. wifi4psp (1 Post)
  241. drian (1 Post)
  242. su-aska (1 Post)
  243. SebTardif (1 Post)
  244. danceric (1 Post)
  245. DTSman (1 Post)
  246. brian.moeskau (1 Post)
  247. Neethi (2 Posts)
  248. sango (1 Post)
Turkiyenin en sevilen filmlerinin yer aldigi xnxx internet sitemiz olan ve porn sex tarzi bir site olan mobil porno izle sitemiz gercekten dillere destan bir durumda herkesin sevdigi bir site olarak tarihe gececege benziyor. Sitenin en belirgin ozelliklerinden birisi de Turkiyede gercekten kaliteli ve muntazam, duzenli porno izle siteleri olmamasidir. Bu yuzden iste. Ayrica en net goruntu kalitesine sahip adresinde yayinlanmaktadir. Mesela diğer sitelerimizden bahsedecek olursak, en iyi hd porno video arşivine sahip bir siteyiz. "The Best anal porn videos and slut anus, big asses movies set..."