ListGrid field can't be shown a second time (regression)

[Osirium1]

To re-create start with the following example:

http://www.smartclient.com/#dataSourceFields

Go to the 'countryDS' and modify one of the fields to have showIf:"false", for example:

{name:"countryCode", title:"Code", showIf:"false"},

Hit 'try it' and it will auto-select the 'view tab'.

Right-click any of the column headers and choose 'Columns'

Click on the hidden column name to reveal it. This will work and a check mark will appear.

Without closing the context menu, click on the column name again to hide it. This will work and the check mark and column will disappear.

Finally click on the column name a third time. This will not work. Seemingly it won't produce a JavaScript error, but nor will the column appear, nor will the tick mark appear.

I've tested this in version: SmartClient_v101p_2016-03-03_PowerEdition, too on OSX and Win8/10 on various browsers, but mostly Chrome.

It seems to be a regression, as it has worked as expected in the past.

[Isomorphic]

showIf is not a valid attribute on a DataSourceField, it applies only to ListGridField. If you add a fields definition to the ListGrid and use showIf:"false" there, the problem you ran into does not occur.

So you will need to correct your code; bear in mind that useAllDataSourceFields means that your ListGrid definitions can be partial, so nothing is repeated. See also the Data Binding chapter of the QuickStart Guide.

[Osirium1]

Ah, that's somewhat frustrating. I do use useAllDataSourceFields for some ListGrids, but usually only to augment a ListGrid with some extra in-browser calculated fields, rather than to override existing ones. However, for those ListGrids that simply draw their fields directly from the dataSource, it feels a bit unnecessary to have to add a fields:[{name:"x", showIf:"false"}].

Suddenly, if I want to change the behaviour, I can't just change it on the datasource definition, I have to search through my codebase and ensure that every instance of the override gets changed, too. That seems a lot more brittle.

I've found that specifying showIf on the DataSource field has been a very nice way to DRY up my code, particularly when the DS is reused by several ListGrids.

I agree with the sentiment that using something in an undocumented way that then breaks is not a regression. Would you consider the above as a good reason to allow showIf to be defined on a datasource field?

Thanks

[Isomorphic]

Why aren't you using detail=true?

[Osirium1]

Because, as far as I'm aware, 'detail' is property, set when the field is defined.

By contrast, showIf can be a string function, so showIf:"userInterface.showTimestamps", for example, will be evaluated every time the datasource is used in a newly instantiated ListGrid.

Again, it's a case of being DRY. I generate a load of DataSources programatically, for each model of my app. I generate a created_at and deleted_at field for each datasource using a createTimeStampField function.

With the single line showIf:"userInterface.showTimestamps", I can toggle showTimestamps and all ListGrids created from that moment on will have visible timestamp columns. To achieve the same, but having set those time stamp fields to details, I'd have to look up those two fields in every single datasource and change the property to reflect the new value of whether they should be shown or not.

I separately use the detail property on ListGrids where the column is truly representing a detail and perhaps I have an expansion component that displays the detail fields.

I hope that makes sense?

[Isomorphic]

It makes sense for someone only using ListGrids. If you were using DynamicForms or other components with your DataSources, you'd discover that your showIf was also active for those components, with consequences you probably didn't intend. This is one of a few reasons why "cheating" by trying to use component-specific properties on a DataSource doesn't work and isn't supported.

If this is a repeating pattern, a simple solution is subclassing ListGrid and adding code to auto-hide these fields, then using your ListGrid subclass pervasively.

[Osirium1]

Ironically, historically, I took the other approach. With DynamicForms, that I use less frequently, I process the fields to strip out attributes that yield unwanted behaviour. As I already commonly use a subclassed ListGrid, I will adjust it as you propose and I think that will be a better solution.

Thanks!