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 -~----------~----~----~----~------~----~------~--~---
