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":
- 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
- 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.
- 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.
- Provide simple client side table model taking a list or array of the
row
values
- Provide some cstr. in PagingScrollTable that implicitly generated
this
client side table model
This would lead to a PagingScrollTable construction as simple as
List<Student> myStudents = new ArrayList<Student>();
...adding students...
PagingScrollTable<Student> pst = new PagingScrollTable<Student>
(myStudents,
myTableDefinition);
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.
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;
}
}
List<Student> myStudents = new ArrayList<Student>();
...adding students...
PagingScrollTable<Student> pst = new PagingScrollTable<Student>
(myStudents);
Is this too funky?
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
