[gwt-contrib] RFC: Fixed width column support in CellTable
John LaBanca
-
Summary
-
Currently, CellTable resizes naturally based on its content, which usually isn't the desired behavior. Columns change widths on each page based on the new contents, which looks bad when paging through a table. When clicking on a Cell to go into edit mode, the Column will resize to fit the editable input. We need to give users more control over the column width. Both of these issues can be seen in the Showcase sample (try paging and clicking on somebody's first name).
-
Technical Details
- Set the table-layout to fixed
- Set the table width to 100% (optional)
- Set the width of some or all columns using the col tag
- If the widths of all columns are set, the width becomes a weight and the columns are resized proportionally
- If the widths of some columns are set, those columns are fixed and the remaining width is divided evenly over the other columns
- This allows one or more columns to take the remaining width
- This also means that the width is divided consistently, not based on the content
- If the table's width is too narrow to fit the specified column widths, the table will overflow
- The width in the col tag is basically the hard minimum width
- Columns that do not have widths are invisible if their is no room for them
- Set the table width to 100% (or some other size)
- Set the width of all columns
There is one cross-browser approach that allows users to specify a width for some or all columns and still lets the table resize naturally in a predictable way:
The following native behaviors are consistent across all browsers. In all cases, the default behavior works very well.
We also want to support a table with a width other than 100% (ex. no width specified or a fixed pixel size). However, if the table width is not specific and table-layout is fixed, columns are 0px wide (invisible) by default, which is not a good default use case. In practice, we must do at least one of the following for columns to be visible:
-
Proposal
Column Widths
I propose that we add an interface ColumnWidths that returns the desired width of the specified column. The default implementation will have a map of Column objects to the desired width. CellTable will have a method to setColumnWidths(ColumnWidths). This works for both fixed layout and non-fixed layout (normal) CellTables.
interface ColumnWidths {
/**
* Get the desired width of the specified column.
*
* @param index the index of the column
* @param column the Column
* @return the width as a string (ex. 200px)
*/
String getColumnWidth(int index, Column<?,?> column);
}
class DefaultColumnWidths {
void clearColumnWidth(Column column) {
map.remove(column);
}
String getColumnWidth(int index, Column<?,?> column) {
return map.contains(column) ? map.get(column) : null;
}
void setColumnWidth(Column column, int width, Unit unit) {
map.put(column, width + unit.getType());
}
}
class CellTable {
...
-
// Update the column widths.
-
void refreshColumnWidths();
-
// Set the column widths.
-
void setColumnWidths(ColumnWidths);
...
}
Users can use the DefaultColumnWidths implementation, or they can implement their own version. For example, a user defined ContentColumnWidths could base the column width on the content in the table. This approach ties the column width to the view, not to the Column itself, so users can use different widths for mobile and desktop views.
Fixed Layout
In addition, we need a way to set the table layout to fixed instead of the default of auto. The main difference is that with "auto" layout, a column will never truncate contents; it will expand as needed, even exceeding the specified width. With "fixed" layout, the content will be truncated. Also, if the table width's is set with auto layout, the column sizes are based on the content and are unpredictable. Auto layout is useful when the table data is static (or at least does not page). Fixed layout is preferred when paging, or when you don't want the column width to change automatically every time the content changes.
Fixed: truncate cells, divide extra table width evently over columns (predictable)
Auto: never truncate cells, divide extra table width based on cell contents (unpredictable)
Most users will want a fixed table layout so the specified column widths are taken as more than suggestions, but they may not know that because its an obscure DOM style property. I propose that we add overrides to setColumnWidths() that take a boolean to indicate fixed/auto table layout and a table width parameter. The default method will set the table layout to fixed.
NOTE: If we just add a simple boolean setter to toggle between fixed/auto layout, users may not discover it and wonder why their ColumnWidths don't work as expected.
class CellTable {
...
// Set the column widths and set table layout to fixed, but don't change the table width.
void setColumnWidths(ColumnWidths);
// Set the column widths and table layout, but don't change the table width.
void setColumnWidths(ColumnWidths, boolean isFixed);
// Set the column widths, table layout, and table width
void setColumnWidths(ColumnWidths, boolean isFixed, String width);
// Set the column widths, table layout, and table width
void setColumnWidths(ColumnWidths, boolean isFixed, int width, Unit unit);
...
}
Scrolling
The next feature to add to CellTable is a scrolling content area with a fixed header and footer. This proposal works because we can separate the header/data/footer tables into three seperate tables and still line them up reliably.
Unsupported Features
Maximum SizeWe will not support a maximum size on columns because not all browsers support the max-width style attribute.
Mix Fixed and Proportional Distribution
In the proposal above, you can fix the width of some columns and distribute the remaining width equally over the remaining columns, but you cannot distribute the remaining width proportionally. This isn't natively supported and would require active layout, which isn't worth the performance cost. Users could implement a version of ColumnWidths that supported this by providing new ColumnWidths every time the table is resized.
-
User Resizeable Columns
Under the above proposal, we will not support user resizable columns where the user can click and pull a column header to change its width. The calculations that PagingScrollTable use to support this requires the user to specify the width in pixels (the above proposal allows relative sizes) and requires expensive active layout that causes performance issues. It should still be possible for users to build on top of the above proposal, but it isn't a feature we plan to add to CellTable.
John LaBanca
jlab...@google.com
Stephen Haberman
Sounds really cool.
That being said, you said "RFC"...so... :-)
> This approach ties the column width to the view, not to the Column
> itself, so users can use different widths for mobile and desktop
> views.
Personally, I'd rather just do:
column.setWidth(20, Unit.PX);
Than the ColumnsWidths abstraction.
...besides, in canonical GWT MVP, wouldn't you do something like:
interface XxxView { HasData<T> table(); }
class MobileView {
void foo() {
columnA.setWidth(20, Unit.PX);
}
}
class DesktopView {
void foo() {
columnA.setWidth(200, Unit.PX);
}
}
...are you really going to want to share widths across desktop/web? Or,
even if you do, should that be something your presenter worries about?
I suppose if the widths relative--but even if the widths are relative,
it still seems like that is a code reuse concern between the views, and
not something the presenter should be concerned about.
(Look at that, Column is even an abstract class, so you can add setWidth
without a breaking change. ;-) )
- Stephen
John LaBanca
Stephen Haberman
> We could JavaDoc it, but I wish it was more discoverable in the API.
Hm, would a CellTable overload of setWidth be good enough, e.g.:
table.setWidth(String width, boolean isFixed);
This seems more discoverable than the get/setLayoutFixed toggle that,
I agree as you mentioned, might get lost in the CellTable method list.
- Stephen
John LaBanca
Thanks,
John LaBanca
jlab...@google.com
Hm, would a CellTable overload of setWidth be good enough, e.g.:
> We could JavaDoc it, but I wish it was more discoverable in the API.
table.setWidth(String width, boolean isFixed);
This seems more discoverable than the get/setLayoutFixed toggle that,
I agree as you mentioned, might get lost in the CellTable method list.
Thomas Broyer
Miroslav Pokorny
John LaBanca
I suggest this for two reasons:
- We don't need a CellTable#refreshColumnWidths() method because CellTable always knows when the width changes. Both the ColumnWidths proposal and Column#setWidth() have the problem that the table isn't notified of the change. We could add event handlers to ColumnWidths/Column, but thats a bit of overkill.
- I'm not 100% sold on Column#setWidth() because its possible to use the same column in two tables but have different widths. For example, a source table and a destination table that both contain a summary column.
Minor suggestion but would not ColumnWidthSource be a better name than ColumnWidths, after all it is a source of column widths given a column. When i see classes w/ plural names, i think of classes w/ static helpers java.util.Collections. Guice is another example of this naming style.
John LaBanca
Stephen Haberman
> 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
Thomas Broyer
On Thursday, January 6, 2011 11:34:17 PM UTC+1, Stephen Haberman wrote:
> 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 readprivate 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.
vela.i...@gmail.com
How must I install this patch in my enviroment?
John LaBanca
John LaBanca
jlab...@google.com
Hi, I need to use this patch, but I'm really losed about how to download and use it.
How must I install this patch in my enviroment?
vela.i...@gmail.com
Regards.