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 List<List<Object>>
>
>
> - 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);
+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;
> }
> }
>
> List<Student> myStudents = new ArrayList<Student>();
> ...adding students...
> PagingScrollTable<Student> pst = new PagingScrollTable<Student>
> (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
-~----------~----~----~----~------~----~------~--~---
