Re: Bruce's point about expectations and features vs. performance. Has there been (or should we start) discussion for the public record of different facets/features of tables, their impact on performance, and their possible class structure? What I'm thinking of specifically is bulk rendering vs. dynamic model-backed tables, scrolling, paging, and all the combinatorial permutations thereof. Will supported features be part of a single class hierarchy as they are in Incubator (i.e., PagingScrollTable extends ScrollTable; paging code is bound to scrolling code, although scrolling can be disabled it would still add code to the compiled app)? Or will they be pluggable features into a base Table class (like MonthSelectors for DatePickers)? Or separate implementations of a common Table interface?
- Isaac On Wed, Jun 10, 2009 at 11:27 AM, Bruce Johnson <br...@google.com> wrote: > I'll be the bad guy and try to lower expectations: whatever we end up doing, > it has to be fast. We've seen some *horrible* usability problems with fancy > tables -- even at a small number of rows -- and so don't be surprised if we > have to pare back features and reduce API flexibility to ensure that a few > key use cases are sufficiently high performance. > > -- Bruce > > On Tue, Jun 9, 2009 at 10:12 AM, John LaBanca <jlaba...@google.com> wrote: >> >> We'll definitely keep these things in mind when moving stuff over to GWT >> trunk. We've also found a lot of general usability problems, such as the >> fact the the table doesn't layout naturally, which means apps require active >> layout. During the transfer, we'll refactor quite a few things to make them >> more usable. Specifically, we'd like to provide a version that allows you >> to bulk renderer the header and footer into the same table element, >> eliminated the three separate tables and fixed layout. You would lose the >> scrolling feature, but you would not have to use active layout. >> >> When we start moving stuff into trunk or while its in my branch (as in >> right now), thats a good time to point out specific problems or requests. >> Its much harder to change the API after we make an official release. >> >> Thanks, >> John LaBanca >> jlaba...@google.com >> >> >> On Tue, Jun 9, 2009 at 5:01 AM, David <david.no...@gmail.com> wrote: >>> >>> Jay, >>> >>> We are experiencing the same ideas here. We store column ordering and >>> widths on the server but we have no way of getting events in the UI to >>> know when changes have been complete. >>> >>> wouldn't it be nice that the dnd was included as well, I could really >>> use the DND of columns! Was it hard to implement ? We did not yet >>> bother to investigate since we have to focus on getting functionality >>> complete first. >>> >>> David >>> >>> On Tue, Jun 9, 2009 at 10:00 AM, jay<jay.gin...@gmail.com> wrote: >>> > >>> > As I see that this has begun (yeah!!!!), I'd like to throw out a few >>> > requests: >>> > >>> > * Please, please, please -- ensure that this is as extensible as >>> > possible. Here's just one example--I've integrated the gwt-dnd library >>> > to allow drag-n-drop re-ordering of columns. There are a couple of >>> > funny corner cases, though, because I have no way of knowing when a >>> > column resize has completed. Obviously, if you're resizing the column, >>> > you're not interested in dragging it to a new location. I strongly >>> > encourage you to think three, four, five times about making a method >>> > private or package protected. Liberal use of JavaDoc with strongly >>> > worded warnings to those of us who need to customize the widgets. I >>> > know this cuts down on your ability to make under-the-cover changes >>> > from release to release, but it makes it so that folks like me don't >>> > have to resort to things like JSNI trickery or copying the entire >>> > class or set of classes into our own code base. >>> > >>> > * As a direct follow up to #1, fire some more events. For example, >>> > fire an event when a column resize starts and when it ends. >>> > >>> > * Flexibility is great, but often I'm just interested in the simple >>> > cases...simple. My example here is the multiple-row header stuff. It's >>> > GREAT! I LOVE it! (And better yet, our customers have been screaming >>> > for this!) But, I don't always need/want it. And, it can make things >>> > more complex. One idea would be to overload methods like getHeader() >>> > on AbstractColumnDefinition...add a version that doesn't take a 'row' >>> > parameter, and so just assumes there's only 1 row. >>> > >>> > * More use of generics, less casting (for me). Some examples: >>> > o AbstractColumnDefinition returns Object for the getHeader() >>> > method. Why not declare this as class >>> > AbstractColumnDefinition<RowType, ColType, HeaderType>? >>> > o Rather than: "public TableDefinition<RowType> getTableDefinition >>> > ()", how about adding a TABLE_DEFINITION type to the class (e.g., >>> > "class PagingScrollTable<TABLE_DEFINITION extends >>> > TableDefinition<RowType>>, so that the method could be declared as >>> > "public TABLE_DEFINITION getTableDefinition()"? >>> > >>> > >>> > I apologize if I'm being overly simplistic or if I'm asking too much. >>> > I definitely apologize for not following up my suggestions with >>> > proposed patches. And I sincerely hope that my suggestions are taken >>> > only as the most positive form of feedback possible. I LOVE GWT. We've >>> > bet our company on the fact that GWT is *the* best way for writing the >>> > kind of interactive and rich apps our users are demanding. I want to >>> > do whatever I can (with my limited time outside of my job) to help >>> > make this toolkit even better. >>> > >>> > Thanks! >>> > >>> > jay >>> > > >>> > >>> >>> >> >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
