Table column manipulation in runtime

Andrzej Michalec

January 17, 2017 at 11:18 am #3504

Hello.
I am facing some serious limitations manipulating on Table columns definitions:

1) Column runtime renaming is impossible. Column name is read from coach view (CV) label that is placed during design time. Label is read only when static value is used. When label is bound to variable (e.g. to configuration option of wrapping CV) set before load phase of table, it renders empty column label. There is no formal/public interface to rename column dynamically.

2) Columns runtime hiding (or any columns spec modification) is impossible. Undocumented JavaScript function setColumns() does not work – when executed it makes all columns named “undefined”. Variable bound to “columns” configuration option (type of TableColumn, column specification) is read only on load, when definition changes later e.g by marking some columns as invisible (setting “N” to “visibility”), this change is not detected. Also rebinding whole “columns” property to new list is ignored.

 

 

Since table is fundamental widget (in many UI technologies) I am expecting Salient to made it as flexible as possible and I advocate following steps (that can be formed as PMR request if necessary):

a) Introduce consistent interface for column manipulation –– JavaScript API along with configuration options — same as in case of other properties e.g. label can be set in design time, statically or by variable binding, or using setLabel() JS API.

b) Make table responding to column manipulation in runtime, not only during load phase but later in lifecycle.

c) Enhance column functionality — next to existing properties allow columns renaming with respect to localization resources, allow to delete, reorder columns etc. Adding new columns in runtime mentioned here (e.g. for coach views that can be created programatically like dojo widgets) would be a nice bonus (this feature is not hard requirement for us though).

 

My workaround uses CSS and DOM manipulation to achieve expected behaviour, so severity of reported issues is not critical. However hacks are brittle by nature; changes to HTML structure of table widget in future SPARK releases can silently break my solution. I would expect permanent solution within one or two releases away.

regards,
-andy.

SPARK Support

January 23, 2017 at 5:01 pm #3549

Hi Andy,

The setColumns() method is intended to be used with the Service Data Table control only.  We have recently corrected our documentation to remove this method from the Table control.  You are correct that the label property is captured from the control labels.  For the Service Data Table, the variable type ServiceDataTableColumn does not contain a Label property.  You are also correct that manipulating column variables does not cause any automatic updates.

Please remember as an Enterprise customer, you have the ability to submit specific Enhancement Requests through our ticketing system.

Regards,

Stephen P.

Andrzej Michalec

January 24, 2017 at 5:58 am #3559

Hi Stephen,

I agree with you point of enhancement request, I just wanted to make sure issues we face go public to benefit every user of this forum (whether it is current or prospect customer).

regards,
andy.

SPARK Support

January 25, 2017 at 2:56 pm #3569

Hi Andy,

I do have an Enhancement Request open to add a getColumns() method to the Service Data Table which will allow runtime manipulation of column data with the available setColumns() method (again, for Service Data Table only).

Regards,

Stephen P.

Ramesh Sahu

August 21, 2018 at 2:50 pm #5242

I have a Table control nested in another custom coach view and have a requirement to hide certain columns depending on further user interactions on the custom coach view) and then show it back(if need be). Is there any support for this functionality that will help me accomplish controlling the visibility of the columns of a Table control in the behavior of the coach view without making a boundary event(which seems to be working) ?