Scout/Concepts/TablePage
Scout |
Wiki Home |
Website |
Download • Git |
Community |
Forums • Blog • Twitter • G+ |
Bugzilla |
Bugzilla |
Table-oriented page
Contents
Description
In outline based application, the child-pages are represented a nodes in the page tree. The cell of this node is defined by the summary cell of the table.
Here an example with only the Name column as summary column:
Here an example with Id and Name column as summary column:
In case of multiple summary column, the texts are concatenated (with a space as separator). A column can be set to a summary column by overriding the following method:
@Override protected boolean getConfiguredSummary() { return true; }
Screenshot
Properties
Defined with getConfiguredXxxxxx() methods.
Force the user to use the search form
With the Property SearchRequired you can indicate whether the data can be displayed without searching (value false, default value) or if the user need to click on the search form to get any data (value: true).
In the second case, to indicate to the user that he should search instead of waiting for the data, an warning is displayed in the table status bar: Large dataset. Please narrow using the search function.
Events
Defined with execXxxxxx() methods.
child page and virtual child page
CreateChildPage is triggered for each row of the table (the corresponding row is given as parameter). It is possible to get some of the values in the table to pass them to the chid page.
@Override protected IPage execCreateChildPage(final ITableRow row) throws ProcessingException { MyNodePage childPage = new MyNodePage(); childPage.setId(getTable().getIDColumn().getValue(row)); childPage.setName(getTable().getNameColumn().getValue(row)); childPage.setComment(getTable().getNotesColumn().getValue(row)); return childPage; }
For performance reason, because sometimes instantiating a page can be expansive, the concept of virtual page was introduced. Virtual pages are created by CreateVirtualChildPage. Virtual pages act like a proxy: only when they are activated the real corresponding page is instanciated with the corresponding call to CreateChildPage.
It is possible to have child pages only for some of the rows. Imagine a Table Page representing some files (like in a file system):
The implementation is simple: if it should be no child page, CreateChildPage should return null.
@Override protected IPage execCreateChildPage(ITableRow row) throws ProcessingException { if (CompareUtility.equals(FileTypeCodeType.FolderCode.ID, getTable().getTypeColumn().getValue(row))) { FolderTablePage page = new FolderTablePage(); page.setParentId(getTable().getIDColumn().getValue(row)); return page; } else { return null; } }
Because of the Virtual pages mechanism, this will not work as expected. One virtual page for each rows of the table (folder and file). On clic on a child page representing a file, the node will disappear. This is because on clic on the virtual page, the real page will be instantiated (by calling CreateChildPage for the corresponding row). The method will return null, meaning no child page for this row.
It is important to implement CreateVirtualChildPage with according to CreateChildPage: if CreateChildPage returns null, CreateVirtualChildPage should also return null.
An implementation could be:
@Override protected IPage execCreateVirtualChildPage(ITableRow row) throws ProcessingException { if (isFolder(row)) { return super.execCreateVirtualChildPage(row); } else { return null; } } @Override protected IPage execCreateChildPage(ITableRow row) throws ProcessingException { if (isFolder(row)) { FolderTablePage page = new FolderTablePage(); page.setParentId(getTable().getIDColumn().getValue(row)); return page; } else { return null; } } private boolean isFolder(ITableRow row) { return CompareUtility.equals(FileTypeCodeType.FolderCode.ID, getTable().getTypeColumn().getValue(row)); }
A related topic is child page decoration: If some decoration occurs on the child page, the page will be decorated only after a user clic:
This is again because of the virtual page. The virtual page has no idea of the decoration of the real page it represent. The virtual page only display information of the summary cell of the row.
Often the table contains enough information to compute the decoration of the child page. A solution is to compute the cell decoration in the table (as summary cell) instead of in the child page. A possible solution is to add an invisible column (displayable == false). This column is defined as summary column (summary == true).
@Order(1000.0) public class SummaryColumn extends AbstractStringColumn { @Override protected boolean getConfiguredDisplayable() { return false; } @Override protected boolean getConfiguredSummary() { return true; } @Override protected void execDecorateCell(Cell cell, ITableRow row) throws ProcessingException { final StringBuilder sb = new StringBuilder(); sb.append('['); sb.append(getIDColumn().getValue(row)); sb.append(']'); sb.append('['); sb.append(getNameColumn().getValue(row)); sb.append(']'); sb.append('['); sb.append(getNotesColumn().getValue(row)); sb.append(']'); cell.setText(sb.toString()); } }
There is no need to decorate the child page, because the summary cell will be used on both the virtual and the "real" child page.
Other events