Issue #188 has 40 stars, making it number seven in the issue list (when sorted appropriately). Let's shoot for number one before John gets back to working on it. ;-)
So if you're anxious for PST to leave the incubator, star this issue: http://code.google.com/p/google-web-toolkit/issues/detail?id=188 - Isaac On Thu, Jul 16, 2009 at 10:58 AM, John LaBanca<jlaba...@google.com> wrote: > We probably won't decide what to move into trunk until we get closer to the > next release. I'm working on improving our unit test coverage to make GWT > more stable, and most of the other UI developers are busy on their own > tasks. Sorry I don't have a better answer, but I'll escalate the fact that > quite a few people have been asking about the table and would like to see it > in trunk. > Thanks, > John LaBanca > jlaba...@google.com > > > On Wed, Jul 15, 2009 at 6:31 PM, jay <jay.gin...@gmail.com> wrote: >> >> Bump again? Any status? >> >> thanks... >> >> jay >> >> On Jul 7, 8:40 am, jay <jay.gin...@gmail.com> wrote: >> > bump. Anything? >> > >> > On Jun 24, 10:31 am, jay <jay.gin...@gmail.com> wrote: >> > >> > >> > >> > > Just curious if the effort has been resumed? Regardless, is there >> > > anyway for you to commit what you do have somewhere we could look and >> > > provide feedback? >> > >> > > thanks, >> > >> > > jay >> > >> > > On Jun 10, 8:28 am, John LaBanca <jlaba...@google.com> wrote: >> > >> > > > @jay - I got side tracked with other tasks, but I'll pick up the >> > > > PagingScrollTable effort within a couple of weeks. The main goal >> > > > when we >> > > > transfer the PagingScrollTable to GWT trunk is to separate the >> > > > concept of >> > > > scrolling (with three distinct tables) from the rest of the code. >> > > > That way, >> > > > we can bulk render a single table element that includes the >> > > > header,data, and >> > > > footer and have it layout naturally. >> > >> > > > @dflorey - I definitely plan to include all three of your points >> > > > into the >> > > > scroll table. Thanks again for all your contributions. >> > >> > > > I don't know exactly how long it will take to integrate everything >> > > > into the >> > > > GWT trunk, but its one of my highest priorities. >> > >> > > > Thanks, >> > > > John LaBanca >> > > > jlaba...@google.com >> > >> > > > On Wed, Jun 10, 2009 at 10:15 AM, dflorey <daniel.flo...@gmail.com> >> > > > wrote: >> > >> > > > > 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 <jay.gin...@gmail.com> 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 <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 -~----------~----~----~----~------~----~------~--~---
