PDA

View Full Version : [OPEN EXTJSIV-2533] Variable row height and Infinite Scrolling grid



stevil
20 May 2011, 11:47 AM
Ed's blog on Infinite Scrolling grids includes the line: "This delivers two enormous benefits the ability to have variable row heights, and the ability to expand and collapse rows at any time."

Is there anything I need to do to enable this feature?

I have a grid in which I've set one column's renderer to a function that wraps the text content in a DIV, with white-space: normal to allow the content to wrap.

This works, up to a point - the DIV will cause the text to wrap, but, if it expands the row beyond the "normal" row height, then the scroller will only allow me to see a subset of rows in the grid. (Say, 96 out of 110 rows if I resize the column down to make the DIVs expand (and therefore, their grid rows). Same if I just render the grid outright with a narrow column).

Are there any tricks I'm missing to getting this to work?

cheers,

stevil

jsakalos
22 May 2011, 2:28 AM
I haven't tried it personally but it can be a bug. Can you provide a simple showcase?

mike.estes
16 Jun 2011, 12:12 PM
moved this thread to Ext:Bugs, this is filed as EXTJSIV-2533

stevil
16 Jun 2011, 12:24 PM
moved this thread to Ext:Bugs, this is filed as EXTJSIV-2533

Thanks Mike, I was able to make this happen by using a cell renderer that wraps the content in a DIV with normal white-space:



app.renderVariableHeight = function (val, meta, record, rowI, colI, store) {
return Ext.String.format('<div style="white-space: normal; ">{0}</div>', val);
}

locutusUT
21 Jun 2011, 5:46 PM
I've noticed that the scroll bar for a buffered grid will not properly size/scroll for the number of rows that are actually returned if I have word wrap enabled on the rows. See this image (http://screencast.com/t/Z0p7SWDRYP) for details.

I'm using the following renderer to adjust the CSS to allow for word wrapping which is required for my application:


function columnWrap(val){
var style = '';
if (Ext.isIE) {
style = '<pre style="font: normal 11px tahoma,arial,verdana;overflow:hidden;word-wrap:break-word";>' + val + '</pre>';
}
else {
style = '<div style="word-wrap:break-word;white-space:normal !important;">'+ val +'</div>';
}
return style;
}

mike.estes
21 Jun 2011, 6:45 PM
This is filed as EXTJSIV-2533, merging this into the existing thread

locutusUT
22 Jun 2011, 10:40 AM
Thanks Mike. I showed a demo of the new infinity grid to our development team this morning. Needless to say they were impressed! :) Once we get the scrolling issues knocked out, it's going to be a big plus to have in our arsenal for working with large dynamic data sets.

stevil
22 Jun 2011, 10:57 AM
Thanks Mike. I showed a demo of the new infinity grid to our development team this morning. Needless to say they were impressed! :) Once we get the scrolling issues knocked it, it's going to be a big plus to have in our arsenal for working with large dynamic data sets.

Indeed - we were using Ext.ux.LiveGrid, and don't get me wrong, Thorsten does great work - in fact, props to him for pioneering work in this area! However, having the support baked into the framework is much nicer - less to deploy, easier to configure, bundled support under one license, etc.

stevil

SebTardif
7 Aug 2011, 1:29 PM
We need the same. If Sencha could add this in their official examples that would be great trustable marketing. We do know one of the competitor that is unable to handle that by design.

Animal
8 Aug 2011, 5:44 AM
I cannot see how this could ever be implemented.

SebTardif
8 Aug 2011, 5:53 AM
Ed's blog on Infinite Scrolling grids includes the line: "This delivers two enormous benefits the ability to have variable row heights, and the ability to expand and collapse rows at any time."

I cannot see how this could ever be implemented.

If you see Ed, you should ask him. It's not the first marketing statement he made that seem opposite to the true.

stevil
8 Aug 2011, 6:33 AM
I cannot see how this could ever be implemented.

@Animal,

That was my initial reaction, because the only way to make it reliable AND not perform like a dog would be to make an assumption about the row height, you can't possibly predict the height of rows whose data has yet to arrive!

But then in http://www.sencha.com/blog/infinite-grid-scrolling-in-ext-js-4/, Ed says:


... The new system only renders a handful of rows at a time, seamlessly swapping out data as you scroll. Unlike other infinite scrolling solutions, we are not simply recycling existing rows and replacing their values each row is still being rendered just like normal. This delivers two enormous benefits the ability to have variable row heights, and the ability to expand and collapse rows at any time. (emphasis mine)

I'm going to be VERY interested to see how this is implemented. We used to use LiveGrid, and switched to the native grid because LiveGrid couldn't handle variable row heights...

stevil

Animal
8 Aug 2011, 8:38 AM
Yes, if we can't know the total pixel height of the entire dataset, then we cannot create that 1px wide, hugely high "stretcher" element within the DataView which causes the scrollbar.

edspencer
8 Aug 2011, 9:31 PM
But then in http://www.sencha.com/blog/infinite-grid-scrolling-in-ext-js-4/, Ed says:

The perils of being the only one on the team who enjoys blogging... I actually wrote this up based on talking with Aaron (who wrote the grid). As I understand it, a reasonable estimate can be made for the purposes of getting the scroller size close enough to the right size that it appears to be correct. Logically this starts to fall down if all the early rows are short and all the later rows are tall but as you say there's just not enough information present to guarantee that it's spot on.

I'm sending Aaron here for feedback

stevil
9 Aug 2011, 6:01 AM
@Ed,

What about a configurable option on the grid view to always leave some slack at the bottom of the scroller? So, when you're at the bottom of what the view thinks is the end, the scroll thumb is some distance (20-40 px) from the actual bottom of the scrollbar?

When you click it, it just tries to continue scrolling past what we *think* is the end of the data. If it does pass the end of the data, you get nothing - empty space. If, however, there is more data, you can actually get to it.

If you know you have fixed height data - turn the option off and have an accurate scroll experience. If not, perhaps we can live with a little "slop"?

Excel, I guess, offers another model, but it's more confusing - you have to hit the scroll arrows to get it to keep going, and the thumb stays locked at the bottom.

stevil

stevil
9 Aug 2011, 6:02 AM
The perils of being the only one on the team who enjoys blogging...

@Ed,

You need to spread the blogging responsibilities around, and with it, some of the accountability! ;)

steveil

panpur
6 Oct 2011, 7:16 PM
I too had this problem. I've created a workaround to please my boss, so I thought I'd share it.

The idea is too expand scroll view height if the scroller has reached bottom but not all data has been displayed. Here's the partial code, overrides onElScroll function of Ext.grid.PagingScroller:


onElScroll: function(e, t) {
// get average row height for this page
this.rowHeight = this.getPanel().down('tableview').el.first().dom.offsetHeight / this.store.pageSize;

...
...
...

var stretchEl = this.stretchEl.dom;

// check if the scroller has reached bottom but not all data has been displayed, if so expand the scroll view height
if(position + this.el.dom.offsetHeight >= stretchEl.offsetHeight && visibleEnd < totalCount - 1) {
stretchEl.style.height = (stretchEl.scrollHeight + (((totalCount - 1) - visibleEnd) * this.rowHeight)) + 'px';
}

if (me.syncScroll) {
me.syncTo();
}
}


Hope this help someone, at least until official fix released.

jedstark
29 Nov 2012, 7:18 AM
Has this been fixed yet? I'm still seeing the behavior that when variableRowHeight is true and I have CSS to allow word-wrap, I can't scroll the bottom few rows into view, the scrollbar tab just bounces.

Thanks for any updates,
-Jed