Hi, I'd like to support this effort and would be glad if some of my changes would make it into trunk: - filters - column types for most frequently used column types (numbers,dates,text) including proper filtering, editing and sorting capabilities - simplified table generation ( see http://code.google.com/p/google-web-toolkit-incubator/wiki/TreeTable )
(TreeTable is not ready for prime time yet) Daniel On 10 Jun., 05:34, jay <[email protected]> wrote: > 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 <[email protected]> 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 > > [email protected] > > > On Tue, Jun 9, 2009 at 5:01 AM, David <[email protected]> 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<[email protected]> 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 -~----------~----~----~----~------~----~------~--~---
