[gwt-contrib] Re: Proposal: Simplification of ScrollTable
Copy from #190 I like the idea of providing additional default/simple implementations to make constructing a very basic PagingScrollTable easier. Of course, this should be done (if at all possible) without reducing the current flexibility of PST. To address specifics: 1. Consolidating the PST genealogy. This hasn't really bothered me. I haven't personally found a use for ScrollTable, since I'm very much attached to the model-driven PST. AbstractScrollTable just seems like an inheritance artifact, which I find acceptable (although I know that at least one element in the GWT team would dissent). But if consolidation would make things easier/safer/tighter or any other way better, it's worth considering. 2. Adding a title and tooltip to the ColumnDefinitions. This seems reasonable as an option for streamlined PST construction. Caveat retaining flexibility. 3. Provide a default data table. I like this option as well. User's can always pass in their own data table to retain more control over it. 4. Provide simple client side table model taking a list or array. Doesn't this already exist as IterableTableModel? 5. Annotations for column definitions. I'm not a huge fan of this idea, but I can see how some might prefer it. As long as other ColumnDefinition schemes aren't neglected, this seems like an interesting avenue to explore. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposal: Simplification of ScrollTable
I'm a first time gwt user, trying to learn ScrollTable and PagingScrollTable. On Nov 15, 10:20 am, dflorey [EMAIL PROTECTED] wrote: Some more observations regarding PagingScrollTable: Right now the developer is responsible for calling setRowCount on the table model after retrieving data. If you don't call this method you'll get strange results like flashing empty table + endless paging. I didn't call CachedTableModel.setRowCount and PagingOptions smartly didn't show Last button. It shows First, because it knows there is a first record. I experienced the endless paging. Even if you go to first page and hit Previous button it goes to page zero and show the Empty table widget. I was excpecting that not feeding setRowCount was a normal use case, because there are databases where counting is a expensive operation. Unfortunately there is no method like getRowCount() defined in the Response. The if you are using paging in conjunction with remote requests there is no way to get the number of total available rows (they differ from the actual requested rows as they are limited by the page size). Proposal: Add the getRowCount() method to the Reponse and call the setRowCount on the table model in the callback. I've implemented this in my branch. While implementing this I found it very annoying that Iterators are used heavily insted of Collections, so you can never tell easily how many rows are available in total. What is the reason for using Iterators instead of Collections? Maybe it's just me but my guts tell me Iterators are error prone and scaring... --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposal: Simplification of ScrollTable
Some more observations regarding PagingScrollTable: Right now the developer is responsible for calling setRowCount on the table model after retrieving data. If you don't call this method you'll get strange results like flashing empty table + endless paging. Unfortunately there is no method like getRowCount() defined in the Response. The if you are using paging in conjunction with remote requests there is no way to get the number of total available rows (they differ from the actual requested rows as they are limited by the page size). Proposal: Add the getRowCount() method to the Reponse and call the setRowCount on the table model in the callback. I've implemented this in my branch. While implementing this I found it very annoying that Iterators are used heavily insted of Collections, so you can never tell easily how many rows are available in total. What is the reason for using Iterators instead of Collections? Maybe it's just me but my guts tell me Iterators are error prone and scaring... --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposal: Simplification of ScrollTable
See responses inlined.
Thanks,
John LaBanca
[EMAIL PROTECTED]
On Fri, Nov 14, 2008 at 4:57 AM, dflorey [EMAIL PROTECTED] wrote:
I've opened an RFE in the issue tracker (#190) but I'd like to hear
from other developers that already used the new incubator table
package to get an impression whether my thoughts are nonsense or
brilliant ;-)
Right now the table framework is very flexible but fairly complex and
hard
to understand for first time users.
While it is cool to be flexible and allow users to do whatever they
want
I'd like to propose some ideas that may make life easier for the
standard
usercase:
Agreed in principle, but the ScrollTable is becoming more complicated as
time goes on primarily because the simple cases don't satisfy user needs.
However, I fully support default implementations to the extent possible.
- Do we really need AbstractScrollTable, ScrollTable and
PagingScrollTable?
If you have no idea about the data types in the ScrollTable as there
is no
TableModel behind it, it might be hard to provide default sorting and
filtering capabilities.
If we could find a way to simplify the usage of the model based table
we
could merge these classes
I think we need all three classes. The ScrollTable adds client specific
code, while the PagingScrollTable adds TableModel/Paging specific code. For
example, ScrollTable allows people to set minColumnWidths while
PagingScrollTable gets them from the ColumnDefinition. If you're suggesting
that we should always require a TableModel (and possibly create it behind
the scenes), I think that would just complicate the ScrollTable case.
- Adding a title and tooltip to the ColumnDefinitions to be able to
generate the header table automatically.
I guess that in 95% of the cases the header table looks as simple as
displaying exactly one header per column. If we would add this
information
the the ColumnDefinition we could generate the header table
automatically
and could provide a simplified cstr to the PagingScrollTable.
+1. It makes sense for the ColumnDefinition to define the header. We could
even allow it to define a group header. A nice side effect is that we can
automatically handle the case where the user removes columns and rerenders
the table. But whatever form this takes should still allow the user to
create more complex headers (maybe?).
- Provide a default data table and delegate the selection policy and
other
data table specific methods to the nested table.
I've been confused when using the ScrollTables the first time as I
never
knew where to find the proper methods. It would be much more intuitive
if
we could simply call all of these methods on the PagingScrollTable
itself.
Maybe... I'm not sure how I feel about this one.
- Provide simple client side table model taking a list or array of the
row
values
We have on called ClientTableModel that does exactly this. We even have
ListTableModel that takes in a ListListObject
- Provide some cstr. in PagingScrollTable that implicitly generated
this
client side table model
This would lead to a PagingScrollTable construction as simple as
ListStudent myStudents = new ArrayListStudent();
...adding students...
PagingScrollTableStudent pst = new PagingScrollTableStudent
(myStudents,
myTableDefinition);
+1
Now you'd have a complete scroll table with header (taken from table
definition), proper sorting, filtering etc.
If it is as simple as that, I think removing the limited untyped
ScrollTable is of no harm.
I disagree. Why can't we leave it and still implement your ideas.
Another idea that just came to my mind:
If we would add the info needed in the table definition as annotations
in the Student
class, we could provide a default table definition based on the domain
object:
public class Student implements RowValue {
@ColumnDefinition(column=0,title=First name,tooltip=The first
name,
sorting=true, filtering=true, editable=true)
public String getFirstName() {
return firstName;
}
@ColumnDefinition(column=1,title=Date of birth,tooltip=The date
of birth,
sorting=true, filtering=true, editable=false)
public Date dateOfBirth() {
return dateOfBirth;
}
}
ListStudent myStudents = new ArrayListStudent();
...adding students...
PagingScrollTableStudent pst = new PagingScrollTableStudent
(myStudents);
Is this too funky?
Its a neat idea, but it requires the use of a Generator, which means you
would have to GWT.create() the RowValue in order to trigger it. I think
using annotations would be a complicated thing to implement, but certainly a
good long term goal.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
