Hi John, On Nov 2, 6:50 pm, John LaBanca <[email protected]> wrote: > 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. > 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. > 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 -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
