This had originally been reported as a bug in ICE-8573. Adding support for this will help make it easier for developers to intuitively use the panel when using column groups.

(Putting comment into proper field).

Assigned to Mark for re-assignment. As a new feature request, this may not be suitable for inclusion in the upcoming EE patch so I've tracked targeted it for 3.4 for the time being.

Another incompatibility with using the tableConfigPanel with a columnGroup is related to an issue reported in ICE-9055. When displaying the panel in the last column, and if the last column (header row and body column) are not rendered, the button to open the panel is not displayed. Attached is a basic test case that shows this behavior.

In order to achieve this, the ace:dataTable will need to use a new model for the table header region, similar to what is done now for the actual columns. This "headerModel" will:

• Provide the hierarchy of which columns and bottom-row headers are grouped under the other (if any) column header rows.
• Provide the order of the header columns, as indicated by the order of the corresponding table body columns.
• Be initially created to match the initial column header state (from the facelet markup), but can subsequently be modified by the tableConfigPanel component in response to user preference changes to column ordering and visibility.

At render-time, the header renderer will construct the header markup based on a combination of the column order and header-row hierarchy in the model, and by setting the colspan on the header row cells by matching the actual number of rendered child columns under the header row (if any).

Attached whiteboard pic mockup of table scenario with corresponding tableConfigPanel.

For the ace:tableConfigPanel, it will need to modified to support a nested hierarchy of column-groups to configure.

Notes:

• Each header row in the table should be represented as a level in the hierarchy.
• Columns may only be moved within their existing columnGroup header hierarchy.
• Column naming, visibility and sorting can only be set on actual columns, not headers.

It seems possible that the tableConfigPanel could be implemented by nesting multiple instances of what is essentially the current configPanel (one level list of columns), with separate instances/lists for each columnGroup row and set in the header (see whiteboard screenshot). Implementing it this way ensures that the columns cannot be moved outside of their header hierarchy, as the column move feature would limit moves within each configPanel list panel.

Added ColumnGroupModel, which manages a multi-row model of columns, and provides means for iterating/traversing through that 2D space. Added ColumnModel, which binds the header ColumnGroupModel with the body ColumnGroupModel, so that corresponding columns are linked, meaning that when a header column corresponds to a body column, properties need only be set on the header column to be used by both, and when columns are reordered in the TableConfigPanel, future changes to that component will allow corresponding columns to be moved together in a single action.

Outstanding:

• The groupBy property does not work with the corresponding column feature, due to additional refactoring being necessary
• TableConfigPanel needs to make use of the new ColumnModel and ColumnGroupModel APIs
• DataExporter needs to make use of the new ColumnModel and ColumnGroupModel APIs

branch
Subversion 38628

Fixed the groupBy issue by refactoring the code to split out what actually needs to be delegated to the header column versus the code that should be delegated to the body column, versus the code that holds it all together.

branch
Subversion 38641

Added support for header column ordering to ace:dataExporter (CSV format and OuterTableCSVExporter) at revision 38678.

Fixed issue with not accounting for stacked columns in the header and issue with not skipping column with expansion toggler (in the header) at revision 36680.

There's only one edge case at the moment that needs to be solved: when a stacked column goes right before a column that spans multiple rows. The headers will appear swapped, only when the row-spanning column is not defined in the row we're processing at the moment.

Fixed edge case with stacked column next to row-spanning column at revision 36681.

TableConfigPanel has been completely redone to use the new ColumnModel and ColumnGroupModel APIs, as well as a new tree-like markup to encapsulate the hierarchy of columns.

Ordering, naming and visibility are working, while sorting re-coding remains outstanding.

branch
Subversion 38684

Fixed an issue with hiding columns that are non-last in a stack. Depending on which one was hidden, there were either DOM warning or exceptions. One of the instances of this was known as:

"DataTable rendering glitches when first column in a stack becomes unrendered. Required 2 uses of tableConfigPanel to reproduce."

branch
Subversion 38693

Added support for header column ordering to ace:dataExporter (XLS, PDF, and XML formats) at revision 38697.

Added copyright notices to new files, added code to respect the columnGroup rendered value, added automatic adjustment of rendered colspan and column rendering that ripples from tableConfigPanel editing of column renderings that affect above and below in the hierarchy.

Note: It's now possible to unrender the whole header and all body columns, and have no way to bring back the tableConfigPanel, except for refreshing the page or adding application code to reset the configuration.

branch
Subversion 38698

• Fix to autoadjusting colspan feature, where 1/n stacked unrendered was causing parent to decrement colspan, when it should only when n/n unrendered.
• TableConfigPanel sorting is now implemented.
• TableConfigPanel auto adjusting of width of header and columns rows to use the maximum necessary width.

branch
Subversion 38704

Made the TableConfigPanel slightly larger, and reduced the length of the header strings, to fix a wrapping problem introduced in the previous commit, and to also allow for longer localised header strings, before we have to make the whole panel auto size itself.

The introduction of auto unrendering of ancestor and offspring columns introduced an issue whereby it became possible to unrender every column so that there would no longer be any shown DataTable header or body, and therefor no means to summon the TableConfigPanel to make any columns be shown again. Previously, before the TableConfigPanel supported ColumnGroup, this was kept from happening by disabling a specific column's visibility control. Now that disabling is removed, and if there is no rendered header, a simple place-holder header row is rendered containing the TableConfigPanel.

branch
Subversion 38706

Fixed the issue with IE7 not showing stacked columns in the TableConfigPanel. Also, removed spacing between columns in the TableConfigPanel, that was initially added to help give space when dragging towards the very top or bottom, but was made unnecessary when sortable(

) was removed.

branch
Subversion 38711

Using the internal QA test app ( http://localhost:8080/dataTable/views/columnHeaderOrdering.jsf ) there was an issue when following these steps:
1. Open the TableConfigPanel, click on UPC to sort, click to accept the changes
2. Click on the Name header to sort
3. Re-open the TableConfigPanel and try to click on UPC again to sort. It won't work, and most interactions won't either, until you close the TableConfigPanel using any of the 3 buttons, then it will work again.

The problem was that the DataTable initiated sort change was causing a fractional part of the TableConfigPanel to DOM update, without it's javascript running, due to ids within the body. Replacing the ids with style classes to act as jQuery selectors works fine.

branch
Subversion 38712

Now when any component in a stack has configurable=false, no part of the stack can be used to reorder the stack. Of course, if a sibling column has configurable=true, then it can be reordered, thus effectively reordering the disabled stack... But at least the UI is more clear.

branch
Subversion 38713

There is an issue with the recent changes for this feature. There is a dependency on having a top level row in the columnGroup with a column that spans the entire width of the table. If this row/column is not present then only the first top level column is shown in the tableConfigPanel. This issue can be reproduced using the test here and removing the 'Track' row/column: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/dataTable/web/views/columnHeaderOrdering.xhtml

Fixed the dependency on the completely spanning top header row, which involved two off by one errors in the iterator, which is used by the traverser, which populates the TableConfigPanel.

branch
Subversion 38719

With this version it is no longer possible to set focus on or edit the col names in the tableConfigPanel (Firefox only)

There is also an issue where the button that opens the tableConfigPanel will be duplicated when set to "last-col" and the last column is in a stack (stacked). Only the topmost will be active, but duplicate buttons are rendered.

Worked around the firefox issue with jquery sortable disableSelection, which was keeping the text fields from being editable. This was not a recent regression.

http://forum.jquery.com/topic/jquery-ui-sortable-disableselection-firefox-issue-with-inputs

branch
Subversion 38720

Added a check so that when a stack of columns are being rendered in the header, the tableConfigPanel summoning button will only get rendered into the first of the stack.

branch
Subversion 38721

Made auto unrendering of ancestor and offspring columns only run when there is a tableConfigPanel, and it's columnVisibilityConfigurable property is true. This allows applications to work-around the new constraint that this feature relies on the column components' rendered properties not being set to read-only EL expressions.

branch
Subversion 38724

There was an issue found with scrollable dataTable and re-ordering columns, that possibly required stacked columns. The scrollable dataTable uses two tables, one for the header and one for the body that also includes a duplicated header that's usually hidden. There was a bug in the rendering of the duplicated headers, where the dataTable changes its container client id so that child components will use a "dupeSeg" addition to their clientIds, so everything remains unique. The problem is that component properties and fields are not reliably accessible, since their values are stored without the "dupeSeg" but are trying to be accessed with it. In this case, headerColumnOrdering was failing, so the duplicated headers were not re-ordered and didn't match the real headers, so messed up the sizing algorithm. I verified this was the issue by bypassing the stored properties that rely on the clientId, and used EL for columnOrdering and headerColumnOrdering, tying them to bean properties, which fixed the un-ordered rendering problem. The real fix came from adding the ColumnModel to the rendering context, so that nothing it relies on will need to be re-gotten during the duplicated rendering, and it also optimises the rendering speed.

To duplicate the issue, use the QA Sparkle Nightly dataTable app and the stackedColumnsAlignmentIssue.xhtml page. Bring up the tableConfigPanel, move the stacked seven and eight columns to come between one and two columns. Click the checkmark, and see that the header and body columns do not line up.

Sparkle/Nightly/dataTable/web/views/stackedColumnsAlignmentIssue.xhtml

branch
Subversion 38757

That didn't actually completely fix the column sizing glitch, since there are actually two problems. The other issue is that a previous commit introduced a regression in the resizing:

Revision #38718 Committed by art.zambrano at 11/1/13 3:44:20 PM ICE-9576, ICE-9532 backported these fixes to this branch

With commit 38757 in, and commit 38718 reverted, it then works properly. I verified that it's not the tableConfigPanel's bug by turning on the reorderableColumns property on the dataTable, and using column dragging instead of the tableConfigPanel, and reproduced the issue with commit 38718 in, which doesn't happen with it reverted.

Reverted ICE-9532 and ICE-9576 joint backport, and added ICE-9576 backport only at revision 38761.

Applications can mistakenly mismatch the header columns and body columns, by having an incorrect number of columns in one, or having a mismatched total of colspan between them. When the code takes the header columns and tries to find the corresponding body columns, it will now attempt to detect this mismatch, and log a severe message to the server log explaining the problem, and then continue to try to build the mismatched dataTable, so that the developer can see the mismatched columns, to help them resolve the issue.

Example new server log message:

SEVERE: When processing the header columns at row index 0 (zero based), the header column spanning (3) did not match the body column spanning (2)

branch
Subversion Subversion 38760

Backported ICE-9532 and ICE-9649 at revision 38788 to solve column misalignment issues, including issue reported by Mark on November 07.

Improved the auto-adjust colspan/rendered code, to not try to write to the rendered property of a body column that is already set through EL, or literally set to false. And improved the proxy mechanism to use that same criteria for using the body rendered instead of inheriting the header rendered.

branch
Subversion 38805

Fixed an issue with sorting and reordering in ICE-9692.

SEVERE: Error Rendering View[/views/multiRowHeader.xhtml]
java.lang.NullPointerException
at org.icefaces.ace.renderkit.CoreRenderer.resolveWidgetVar(CoreRenderer.java:57)
at org.icefaces.ace.component.datatable.DataTableHeadRenderer.encodeConfigPanelLaunchButton(DataTableHeadRenderer.java:392)
at org.icefaces.ace.component.datatable.DataTableHeadRenderer.encodeTableHead(DataTableHeadRenderer.java:104)
at org.icefaces.ace.component.datatable.DataTableRenderer.encodeTable(DataTableRenderer.java:234)
at org.icefaces.ace.component.datatable.DataTableRenderer.encodeEntirety(DataTableRenderer.java:163)
at org.icefaces.ace.component.datatable.DataTableRenderer.encodeEnd(DataTableRenderer.java:121)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:881)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1786)
at javax.faces.render.Renderer.encodeChildren(Renderer.java:168)
at org.icefaces.impl.renderkit.RendererWrapper.encodeChildren(RendererWrapper.java:49)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:851)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1779)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1782)
at org.icefaces.impl.context.DOMPartialViewContext.processPartial(DOMPartialViewContext.java:148)
at javax.faces.component.UIViewRoot.encodeChildren(UIViewRoot.java:973)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1779)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:413)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:124)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)

Added code to check for presence of TableConfigPanel before trying to render it out, in the case where there are no columns left rendered in which to place the TableConfigPanel button.

branch
Subversion 38829

Added more diagnostic code to the DOMResponseWriter to better detect precisely where in the DOM that an unclosed element is. The previous code relied on the tag name changing to detect the mis-match. This should help us better track down the source of these log messages:

WARNING: Missing end-element for: form[id="sub_2:listPgFrm"] (path: #document -> html -> body -> div -> div -> div -> div -> div -> div -> div -> div -> div -> form)

branch
Subversion 38839

Problem using lazy data model with grouping, since grouping would try to build the group size by iterating through the data until none was available, which could be for millions of row. Added the rows size constraint when appropriate.

branch
Subversion 38865

Tangentially related to this task, I wanted an example to test lazy loading with the new code, but I had to improve the existing showcase lazy loading example to give it a better data set that properly illustrates functionality.

branch
Subversion 39065

Finished backporting enhancements to 4.0 trunk at revision 39452.

Finished backporting enhancements to 3.3 EE maintenance branch at revision 39499.