[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
This has been delayed for a while (maybe Q2 of next year?). We want to refactor the PagingScrollTable and incorporate a ListModel/TreeModel that would apply to multiple widgets and incorporate data binding. It will take some time before anyone has enough time to start working on it. Thanks, John LaBanca jlaba...@google.com On Fri, Oct 9, 2009 at 12:02 PM, Sripathi Krishnan sripathi.krish...@gmail.com wrote: Reviving this old thread .. Has there been a decision on this yet? Just want to know if PagingScrollTable is likely to make it to trunk in a future release. --Sri 2009/10/9 Sri sripathikrish...@gmail.com -- Forwarded message -- From: Bruce Johnson br...@google.com Date: Jul 16, 3:57 pm Subject: Moving PagingScrollTable Friends to Trunk To: Google Web Toolkit Contributors Frankly, we've vacillated on it. The problem is that the currently implementation, though full-featured, really doesn't scale especially well even to medium-sized numbers of rows. Trees have the same problem, as does any similar sort of compound widget. Increasingly, we're thinking that we should redefine the whole effort into designing a family of MVC-style complex widgets. This will require a lot of design work, and we're pretty sure we won't be able to get it done properly in the 2.0 timeframe. So, in terms of your planning, I'd say plan for it *not* to ship with 2.0. On Thu, Jul 16, 2009 at 2:15 PM, jay jay.gin...@gmail.com wrote: I was under the impression (based on conversations with GWT team members) at Google I/O in May), that moving this into trunk for 2.0 was a sure thing. Has something changed? I'll live if this has changed, I'd just like to know. Please...keep us informed... thanks, jay On Jul 16, 8:07 am, Isaac Truett itru...@gmail.com wrote: 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 LaBancajlaba...@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
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
Reviving this old thread .. Has there been a decision on this yet? Just want to know if PagingScrollTable is likely to make it to trunk in a future release. --Sri 2009/10/9 Sri sripathikrish...@gmail.com -- Forwarded message -- From: Bruce Johnson br...@google.com Date: Jul 16, 3:57 pm Subject: Moving PagingScrollTable Friends to Trunk To: Google Web Toolkit Contributors Frankly, we've vacillated on it. The problem is that the currently implementation, though full-featured, really doesn't scale especially well even to medium-sized numbers of rows. Trees have the same problem, as does any similar sort of compound widget. Increasingly, we're thinking that we should redefine the whole effort into designing a family of MVC-style complex widgets. This will require a lot of design work, and we're pretty sure we won't be able to get it done properly in the 2.0 timeframe. So, in terms of your planning, I'd say plan for it *not* to ship with 2.0. On Thu, Jul 16, 2009 at 2:15 PM, jay jay.gin...@gmail.com wrote: I was under the impression (based on conversations with GWT team members) at Google I/O in May), that moving this into trunk for 2.0 was a sure thing. Has something changed? I'll live if this has changed, I'd just like to know. Please...keep us informed... thanks, jay On Jul 16, 8:07 am, Isaac Truett itru...@gmail.com wrote: 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 LaBancajlaba...@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
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
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, jayjay.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
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
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 LaBancajlaba...@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, jayjay.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
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
I was under the impression (based on conversations with GWT team members) at Google I/O in May), that moving this into trunk for 2.0 was a sure thing. Has something changed? I'll live if this has changed, I'd just like to know. Please...keep us informed... thanks, jay On Jul 16, 8:07 am, Isaac Truett itru...@gmail.com wrote: 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 LaBancajlaba...@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
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
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, jayjay.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
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
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, jayjay.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
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
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, jayjay.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
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
I'd definitely like to see the paging ability as an extension (read that as you will: interface implementation, derived class, plug-in behavior, whatever) to the scrolling behavior. I don't really like how the incubator has two totally separate, unrelated classes. I wonder if some performance enhancements could be made by having a TableModel interface which is just read-only, and then only if you need editing would you use a MutableTableModel. I'm just wondering here...I really don't know. Though I'm sure it would have other implications, like a change to the ColumnDefinition (e.g., making it read-only, and having a MutableColumnDefinition?) jay On Jun 10, 9:55 am, Isaac Truett itru...@gmail.com wrote: Re: Bruce's point about expectations and features vs. performance. Has there been (or should we start) discussion for the public record of different facets/features of tables, their impact on performance, and their possible class structure? What I'm thinking of specifically is bulk rendering vs. dynamic model-backed tables, scrolling, paging, and all the combinatorial permutations thereof. Will supported features be part of a single class hierarchy as they are in Incubator (i.e., PagingScrollTable extends ScrollTable; paging code is bound to scrolling code, although scrolling can be disabled it would still add code to the compiled app)? Or will they be pluggable features into a base Table class (like MonthSelectors for DatePickers)? Or separate implementations of a common Table interface? - Isaac On Wed, Jun 10, 2009 at 11: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, jayjay.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
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
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, jayjay.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 AbstractColumnDefinitionRowType, ColType, HeaderType? o Rather than: public TableDefinitionRowType getTableDefinition (), how about adding a TABLE_DEFINITION type to the class (e.g., class PagingScrollTableTABLE_DEFINITION extends TableDefinitionRowType, 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 --~--~-~--~~~---~--~~
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
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, jayjay.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 AbstractColumnDefinitionRowType, ColType, HeaderType? o Rather than: public TableDefinitionRowType getTableDefinition (), how about adding a TABLE_DEFINITION type to the class (e.g., class PagingScrollTableTABLE_DEFINITION extends TableDefinitionRowType, 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
@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, jayjay.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 AbstractColumnDefinitionRowType, ColType, HeaderType? o Rather than: public TableDefinitionRowType
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
Re: Bruce's point about expectations and features vs. performance. Has there been (or should we start) discussion for the public record of different facets/features of tables, their impact on performance, and their possible class structure? What I'm thinking of specifically is bulk rendering vs. dynamic model-backed tables, scrolling, paging, and all the combinatorial permutations thereof. Will supported features be part of a single class hierarchy as they are in Incubator (i.e., PagingScrollTable extends ScrollTable; paging code is bound to scrolling code, although scrolling can be disabled it would still add code to the compiled app)? Or will they be pluggable features into a base Table class (like MonthSelectors for DatePickers)? Or separate implementations of a common Table interface? - Isaac On Wed, Jun 10, 2009 at 11: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, jayjay.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 AbstractColumnDefinitionRowType, ColType, HeaderType? o Rather than: public TableDefinitionRowType getTableDefinition (), how about adding a TABLE_DEFINITION type to the class (e.g., class PagingScrollTableTABLE_DEFINITION extends TableDefinitionRowType, 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
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
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, jayjay.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 AbstractColumnDefinitionRowType, ColType, HeaderType? o Rather than: public TableDefinitionRowType getTableDefinition (), how about adding a TABLE_DEFINITION type to the class (e.g., class PagingScrollTableTABLE_DEFINITION extends TableDefinitionRowType, 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
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, jayjay.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 AbstractColumnDefinitionRowType, ColType, HeaderType? o Rather than: public TableDefinitionRowType getTableDefinition (), how about adding a TABLE_DEFINITION type to the class (e.g., class PagingScrollTableTABLE_DEFINITION extends TableDefinitionRowType, 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
Hi, Another thing that would be usefull is that the table is not generated in one big string and then inserted in the DOM in one call. If the number of rows is big than this can take a long time. In our project we do the rendering in larger chunks. We bulk generate pages of rows and append a TBODY element when a page has been generated. This makes it possible to see the rendering progress instead of just jumping on the screen after many seconds. David On Tue, Jun 9, 2009 at 4:12 PM, John LaBancajlaba...@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, jayjay.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 AbstractColumnDefinitionRowType, ColType, HeaderType? o Rather than: public TableDefinitionRowType getTableDefinition (), how about adding a TABLE_DEFINITION type to the class (e.g., class PagingScrollTableTABLE_DEFINITION extends TableDefinitionRowType, 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
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, jayjay.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 AbstractColumnDefinitionRowType, ColType, HeaderType? o Rather than: public TableDefinitionRowType getTableDefinition (), how about adding a TABLE_DEFINITION type to the class (e.g., class PagingScrollTableTABLE_DEFINITION extends TableDefinitionRowType, 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 -~--~~~~--~~--~--~---
