> CellTable.setColumnWidth(Column col, double width, Unit unit)
Yeah, I like this better.
That being said, I still prefer setWidth, because, thinking how
I'd create a table, with col.setWidth, I could do:
table.addColumn(makeFirstColumn());
table.addColumn(makeSecondColumn());
// ... more 1-line addColumn calls, which are easy to read
private Column makeFirstColumn() {
Column c = new Column() { ... };
c.setWidth(...);
return c;
}
Where as with a separate setColumnWidth call, I'll have to:
Column<T, ?> c1 = makeFirstColumn();
table.addColumn(c1);
table.setColumnWidth(c1, 20, PX);
Column<T, ?> c2 = makeSecondColumn();
table.addColumn(c2);
table.setColumnWidth(c2, 20, PX);
private Column makeFirstColumn() {
Column c = new Column() { ... };
return c;
}
Basically, keeping track of the c1, c2 variables obfuscates the
table.addColumn calls. I suppose a helper method would work:
addColumn(table, makeFirstColumn(), 20, PX);
private void addColumn(CellTable<T> t, Column<T, ?> c, int, unit) {
t.addColumn(c);
c.setColumnWidth(int, unit);
}
Eh.
> 1. We don't need a CellTable#refreshColumnWidths() method because
> CellTable always knows when the width changes.
True, this is nice, although there is precedence of having to call refresh
header/footer is you change things post-render.
> 2. I'm not 100% sold on Column#setWidth() because its possible to use the
> same column in two tables but have different widths.
...true, but it seems like a pretty small boundary case.
Nonetheless, I look forward to using the functionality.
Thanks!
- Stephen
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
