I'd definitely like to see the paging ability as an extension (read that as you will: interface implementation, derived class, plug-in behavior, whatever) to the scrolling behavior. I don't really like how the incubator has two totally separate, unrelated classes.
I wonder if some performance enhancements could be made by having a TableModel interface which is just read-only, and then only if you need editing would you use a MutableTableModel. I'm just wondering here...I really don't know. Though I'm sure it would have other implications, like a change to the ColumnDefinition (e.g., making it read-only, and having a MutableColumnDefinition?) jay On Jun 10, 9:55 am, Isaac Truett <itru...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
