Implementation of Group by on Live grid in gxt...

Hi,

I tried implementing Group by functionality on a Live grid.
But i am facing issue when we scroll down the grid after group by.
Issue : the loader.load method is getting called twice.
The scroll bar fetches the correct set of records at first the loader.load method is called with the correct offset.
But then some how, the same method is called second time with offset as 0 which causes the same records to be fetched always( those displayed initially).

let me know if you need to have a look at the code.
I have overriden the method of Grouping view in a class and extended that class to LiveGridView.java.

Also, please let me know if there is any other way to apply 2 view (GroupingView & LiveGridView) on the same grid at a time.

Sadly, there is no response here :-( I too would like to have a LiveGrid with the grouping functionality. Is the only way to somehow combine the two GXT classes into a new one? Has Sencha not done this? Has any forum member done this and goptten it to work? I'd rather not reinvent the wheel.

Also, in general, why are forum posts going unanswered? Is it because this post is not in the premium support area?

The basic issue with trying to implement this feature is that the livegrid keeps loading more items from the server, and throwing away local items, while the grouping grid view is designed to add extra rows that describe those sets of items.

LiveGridView relies on setting the length of the scrollbar based on the height of each row times the total number of rows, whereas the position is the height of each row times the number of rows above the visible set of rows. Grouping makes this extra complex, since the total height needs to now be rowCount*rowHeight+groupCount*groupHeaderHeight – The current height offset needs to be similarly modified. This means that in addition to passing the paging load result set (offset, totalcount, and rows) now also needs to hold the total number of groups, and the number of groups up until the current top item. This is non-trivial for most databases, and means that a custom GroupingLiveGridView would need to either request it, would need to actually load all rows (and not just a subset), or would need to fake it (and would probably have visual artifacts to deal with).

Next: Expand/collapse. When a region is expanded, its size is headerSize + groupCount * rowSize, very similar to the same formula we're using for calculating the whole scrollbar. In order to enable a user to collapse a group, then expect the scrollbar to be updated accordingly, we need to track the number of items in each collapsed group - probably best to already have the number of items in *each* group, as well as the data that represents that particular group (unless you don't ever need to support methods like collapseAll() or expandAll()). Again, we could get away without extra db queries by simple loading all possible items the first time (thus negating one of the main uses of the live grid, when too many items are in the table to reasonable send to the client), though we probably couldn't fake this, we'd need to just drop support for expand/collapse.

Okay, assuming you have a cheap/tolerable way of loading items from the db with the a) total group count and b) the items in each group and the data it represents (or have picked another option) you also need to know if the top row in the rendered region is the first row in the group, and so should draw the group header at the top. This logic is much easier to create - if index is zero, draw it, otherwise check the row cache for the previous row to see if it is in the same group (this implies that you always *have* the previous row loaded).

With those logical pieces out of the way, this is probably pretty easy to render - use the appearance details from the GroupingView itself to draw each group header, but otherwise use LiveGrid's logic to draw only the rows needed, the scroller, etc.

So, to recap, why haven't we added this ourselves? Most databases are very happy letting you specify a offset and a row count (aka OFFSET and LIMIT), and then you can run a second very simple query to get the total count (something like SELECT COUNT(1) or the like), and these features can be combined with the standard filter (i.e WHERE) or sort (ORDER BY) clauses to get the main grouping, sorting, filtering out of the way. In order to render those headers correctly, we also need the number of groups (unique values for the first order-by), and in order to expand/collapse, we further need the data and the count from within each unique value. Various 'nosql' databases can probably offer these features through map/reduce functions, but it will still mean additional queries, and you'll need to decide if you want to do this just up front (to save on later loads) or on each and every query (in case something changed somewhere in the table). All these factors make it tricky to build a view that consistently not only offers this functionality, but does so in a way that will fit with many common backend server setups.

We welcome additional discussion on the forum on how this could be built, and feel free to ask specific questions about why the various views do what they do. If you have a partial implementation and can share it, we might be able to help flesh out additional details, but without having solutions to the expensive back-end issues listed above, we can't provide a one-size-fits-all option.

Also, in general, why are forum posts going unanswered? Is it because this post is not in the premium support area?

I think you'll find that most questions *have* answers, but do not get marked as [ANSWERED]. At a guess, most users don't bother to check the button once they have what they need, or don't care to elaborate when additional details are requested. At least in this forum (I can't speak for other products) the moderators haven't taken to marking questions as answered on behalf of the users, and unlike SO, there isn't a tangible benefit from marking completed questions as such.

Other GXT team members and I try to answer what questions we have time/knowledge (and have sufficient detail), but we also encourage other community members to help out. There are many users who make an effort to answer questions asked by fellow users, but these too are often left unregarded by the original poster.

Thanks again for a very detailed explaination. To be honest, I think I have underestimated the work involved in the grouping grid. After reading your response, i think I will simply use the Live grid and forego the nice grouping feature for larger tables.

On the point about lack of responses, that is more me expressing my concern about GXT and its support. When I see unanswered questions that linger for months or more, i get worried that Sencha is giving up on GXT. I know the companies main focus is on Touch and ExtJS as can be seen by the lack of any GXT talks at the past SenchaCon.

I am grateful for what GXT has brought to GWT.
Thanks again for your response.

There still seems to be lots of confusion about SenchaCon and the fact that GXT was 'missing' there - while there were no talks scheduled, we did have GXT team members on hand to talk to customers, demonstrate current and prototyped future features, and discuss/resolve issues in customer code. An unconf session was held for GXT to discuss (among other things) tools, performance, and the future of GWT itself, though as an unconf, this wasn't recorded. Everyone who came to the booth seemed to get a lot out of it, though of course my perception of events may have been biased. I can say these two things though: I didn't get the chance to sit down except at mealtime for two and a half days, since our tables were constantly busy, and as the result of meeting even more GXT users in the Minneapolis area, I'm looking forward to announcing the first ever MGUG (or GMUG? TCGUG?) meeting, name subject to change...

Conference sessions take a lot of time to prep, and we elected to focus on the product in the lead up to SenchaCon instead of perfecting Java/GWT talks for a mostly-JavaScript conference. Instead, look for the GXT talks at this year's first ever GWT con, called GWT.create. This will be held both in San Francisco and Frankfurt, and will be entirely about GWT tools, libraries, companies, and best practices. Check out http://gwtcreate.com for more details as they become available.