I'm all for performance, performance, performance. It's why we started using this widget.
My ideal is that you guys focus on the basics, but don't hide things behind private or package local classes/methods, or anonymous inner classes. Make sure that we can get in and extend the widget. Oh, and some judicious JavaDoc warning us where bad code could have performance implications. thanks! jay On Jun 10, 8: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 -~----------~----~----~----~------~----~------~--~---
