Hilites with states

[claudiobosticco]

Hi, I really like the hilites system for grids, as an alternative to having to define CSS styles (which could potentially require changes if the skins are modified).

Unless I’ve missed something, its main limitation is that it doesn’t have states, i.e., for hover or selected.

May I ask if you’ve ever considered, or have plans for, evolutions in this regard? And do you generally think it’s a good idea, or is the classic method preferable?

I was experimenting to see if something like this could be simulated with the current system, and this seems to work:

// array of hilite-objects to apply to the grid
var hiliteArray = [
    {// selected style
        cssText: "color:#FFFFFF;background-color:#279f45;",
        criteria: {
            _constructor: "AdvancedCriteria",
            operator: "and",
            criteria: [
                {fieldName: "isSelected", operator: "equals", value: true},
                {fieldName: "area", operator: "lessThan", value: 500000}
            ]
        }
    },
    {  // normal style
        cssText: "color:#FFFFFF;background-color:#639966ab;",
        criteria: {
            _constructor: "AdvancedCriteria",
            operator: "and",
            criteria: [
                {fieldName: "isSelected", operator: "notEqual", value: true},
                {fieldName: "isOver", operator: "notEqual", value: true},
                {fieldName: "area", operator: "lessThan", value: 500000}
            ]
        }
    },
    {// over style
        cssText: "color:#FFFFFF;background-color:#639966;",
        criteria: {
            _constructor: "AdvancedCriteria",
            operator: "and",
            criteria: [
                {fieldName: "isSelected", operator: "notEqual", value: true},
                {fieldName: "isOver", operator: "equals", value: true},
                {fieldName: "area", operator: "lessThan", value: 500000}
            ]
        }
    }
];

isc.ListGrid.create({
    ID: "countryList",
    width: "100%", height: "100%",
    selectionChanged:function (record, state) {
        record.isSelected = state;
        this.getDataSource().updateCaches({data: [record], operationType: "update"})
    },
    rowOut: function (record, rowNum, colNum) {
        record.isOver = false;
        this.getDataSource().updateCaches({data: [record], operationType: "update"})
    },
    rowOver: function (record, rowNum, colNum) {
        record.isOver = true;
        this.getDataSource().updateCaches({data: [record], operationType: "update"})
    },
    dataSource: "countryDS",
    autoFetchData: true,
    fields: [
        {
            name: "countryCode", title: "Flag", width: 65, type: "image", imageURLPrefix: "flags/24/",
            imageURLSuffix: ".png"
        },
        {name: "countryName", title: "Country"},
        {name: "capital", title: "Capital"},
        {name: "population", title: "Population"},
        {name: "area", title: "Area"},
        {name: "gdp"}
    ],
    hilites: hiliteArray
})

Would this kind of approach be considered “safe,” or do you see any issues with it?

[Isomorphic]

The most natural thing would be to introduce hilite.baseStyle, so when the hilite matches, that baseStyle is returned, as if an override to getBaseStyle() were in place.

With theeapproach you're using, we'd recommend at least switching to refreshRow() instead of updateCaches(), as updateCaches is going to do a lot more work (dataChanged will fire, etc).

We'll look at whether we can quickly add APIs like "recordHasHilite()" or similar so that you can do what you want via a single override of getBaseStyle().

[claudiobosticco]

The most natural thing would be to introduce hilite.baseStyle, so when the hilite matches, that baseStyle is returned, as if an override to getBaseStyle() were in place.

With the approach you're using, we'd recommend at least switching to refreshRow() instead of updateCaches(), as updateCaches is going to do a lot more work (dataChanged will fire, etc).

We'll look at whether we can quickly add APIs like "recordHasHilite()" or similar so that you can do what you want via a single override of getBaseStyle().

Thanks for the suggestion about refreshRow()!

Just to clarify my intent: the main reason I’m trying to leverage hilites is precisely to avoid having to redefine or maintain grid CSS classes. My idea was to use hilites as a more maintainable way to handle visual states without having to redefine the skin’s CSS.

[claudiobosticco]

Hi, I tried using refreshRow(), but unfortunately it doesn't work - the hilite is not updated.
I also tried combining hilites with getCellCSSText, but the latter doesn't get called when hilites are present.

Regarding possible API changes, I wanted to check if my goal is clear: I’d like to use hilites instead of having to define all the styles needed to use getBaseStyle(), while still achieving a visual effect for hover and selection.
So, something like being able to define a cssTextOver and cssTextSelected within the hilite, or having the ability to use an attribute in the criteria which reflects the cellStyleSuffix value of the cell/record.

[claudiobosticco]

Regarding the use of updateCaches(), I realize it might be overkill and potentially even a performance issue, in this case, an API like recordHasHilite() could actually be useful.

At the same time, I wonder why refreshRow() doesn’t work - it seems to have no effect when hilites are involved. Is this a bug, or was it expected?

[Isomorphic]

In retrospect, our advice was wrong, because if the data hasn’t changed, the hilites do not need to be recalculated, and that’s correct behavior.

Aside from the possibility of recordHasHilite(), we’ll look at offering a manual recalculation method. This will take a while to get to, however.

Separately, getCellCSSText() is still called when hilites are used, so if you want to represent styling changes as 3 snippets of CSS that are applied according to the normal, over and selected states, that is doable with a pretty simple override of getCellCSSText, without involving hilites per se.

Hilites mostly exist to allow non-technical users to create shareable definitions of data hiliting.