I saw the initial commit of these classes into your branch, but I haven't seen any additional commits. I'd love to take a look at the current direction, and see what other input I can provide.
jay On Jun 9, 7: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 -~----------~----~----~----~------~----~------~--~---
