CellTable as a replacement for incubator ?

[stuckagain]

Hi,

I have waited a long time to finally get the Incubator table out of my
dependencies ... and now with GWT 2.1 release I realize that my
waiting has been a total waste of time!

The CellTable is a very small subset of the incubator table... I would
rather call it a CellGrid.

in IE8 I see 3-4 seconds 100% CPU just to let the browser calculate
mouse over row highlighting, when showing a lot of rows.

Or am I using it wrongly ? Did I mis some setters or decorator classes
that makes the CellTable something useful beyond the expenses demo ?

David

[John LaBanca]

CellTable isn't a complete replacement of PagingScrollTable, but we put a
lot of work into the API to make it more clear and extensible. We'd like to
create a full featured enterprise CellTable, but we also have a lot of other
projects going on and don't have the dev time to do it right now.

in IE8 I see 3-4 seconds 100% CPU just to let the browser calculate

mouse over row highlighting, when showing a lot of rows.

Have you tried looking at it with SpeedTracer? We tested with large tables
(100 rows), and the hover code is pretty straight forward. In past
applications, we've seen performance problems when hovering due
to descendent style selectors because of the way they are implemented in
browser.

For example, you have this CSS style defined:
.myRandomWidget td {
padding: 3px;
}

And you have a CellTable that is NOT myRandomWidget, then changing the hover
style of the row will cause IE to walk up from every TD in the CellTable
trying to match the style definition. In the degenerate case, where
CellTable is not myRandomWidget, this means walking up to the body element.
This is a native browser implementation, and the only solution is to avoid
descendent style selectors.


Thanks,
John LaBanca

Post by stuckagain
Hi,
I have waited a long time to finally get the Incubator table out of my
dependencies ... and now with GWT 2.1 release I realize that my
waiting has been a total waste of time!
The CellTable is a very small subset of the incubator table... I would
rather call it a CellGrid.
in IE8 I see 3-4 seconds 100% CPU just to let the browser calculate
mouse over row highlighting, when showing a lot of rows.
Or am I using it wrongly ? Did I mis some setters or decorator classes
that makes the CellTable something useful beyond the expenses demo ?
David
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.

[stuckagain]

Hi John,

Post by John LaBanca
CellTable isn't a complete replacement of PagingScrollTable, but we put a
lot of work into the API to make it more clear and extensible.  We'd like to
create a full featured enterprise CellTable, but we also have a lot of other
projects going on and don't have the dev time to do it right now.

And what would be the right time ? I agree that the design looks
sound, but scrolling a table is really something that should be
standard in a table. People working on applications don't want to
spend time writing their own table implementation. And currently there
is still no table available that really uses GWT the way it should.
I've seen multiple enterprise projects that went for GXT mostly
because of the mature set of widgets that just look good without much
effort. This is very nice for prototypes and having a short time to
market ... but for bigger applications these widget sets have a lot of
limitations and can not be easily combined with other widget sets. So
after the prototype phase many realize that they need something else.

Post by John LaBanca
in IE8 I see 3-4 seconds 100% CPU just to let the browser calculate
mouse over row highlighting, when showing a lot of rows.
Have you tried looking at it with SpeedTracer?  We tested with large tables
(100 rows), and the hover code is pretty straight forward.  In past
applications, we've seen performance problems when hovering due
to descendent style selectors because of the way they are implemented in
browser.

I was using the standard google user theme
(com.google.gwt.user.theme.standard.Standard) with no custom styling
at all.

As far as I know speedtracer can not be used in IE ... or did that
change in this release ? I checked with DynaTrace and that one is
telling me that IE is stuck in reflow calculations.

I posted a few messages in GWT contributors a few weeks ago because I
had similar issues on our custom build scrolling table. I was using
decendent styles in their, but after removing them I did not see any
improvement. One thing that did improve the performance by a factor of
10, is to stop using addStyleName or setStyleName in the mouseover and
using the getStyle().setBackgroundColor directly. So maybe it would
already be a big improvement if we could somehow override that way
mouseover and selection styles are applied. Most people only want to
change the background color in mouseover.

Alternatively their could be some changes in CssResource that would
allow us to put some styling code in the CssResource instead, which
would keep a better separation between the presentation and view.

Or we could just wait for IE9 to become the standard browser on
Windows... but in the banking sector many of our clients are reluctant
to move away from IE6 since they still have a lot of sites that only
work in that browser and they don't want to spend money on migrating
these applications.

Post by John LaBanca
And you have a CellTable that is NOT myRandomWidget, then changing the hover
style of the row will cause IE to walk up from every TD in the CellTable
trying to match the style definition.  In the degenerate case, where
CellTable is not myRandomWidget, this means walking up to the body element.
 This is a native browser implementation, and the only solution is to avoid
descendent style selectors.

I know, I never use descendant styles only really simple styles, with
the expense that I need to have a large set of stylenames, but with
CssResource all this is very easy to manage and group. So that is
really a very good feature of GWT.

David

[Geoffrey De Smet]

Post by stuckagain
Hi John,

Post by John LaBanca
CellTable isn't a complete replacement of PagingScrollTable, but we put a
lot of work into the API to make it more clear and extensible. We'd like to
create a full featured enterprise CellTable, but we also have a lot of other
projects going on and don't have the dev time to do it right now.

And what would be the right time ? I agree that the design looks
sound, but scrolling a table is really something that should be
standard in a table. People working on applications don't want to
spend time writing their own table implementation. And currently there
is still no table available that really uses GWT the way it should.
I've seen multiple enterprise projects that went for GXT mostly
because of the mature set of widgets that just look good without much
effort. This is very nice for prototypes and having a short time to
market ... but for bigger applications these widget sets have a lot of
limitations and can not be easily combined with other widget sets. So
after the prototype phase many realize that they need something else.

I also get the feeling that CellTable is the only scalable implementation,
but it lacks a couple of important features to surpass the other and
draw all development to itself,
such as:
- header sorting
- column resizing
- column picker

Extracting those extra features from bikeshed works clunky: there's no
decent integration.
Here's my implementation (ASL license):

http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-guvnor/src/main/java/org/drools/guvnor/client/table/
As you can see I had to create a ColumnMeta class (in the ColumnPicker)
to wrap Column because the Column class doesn't have a "visible" property.
--
With kind regards,
Geoffrey De Smet