Is there any way to intercept the change of visibility for a ListGrid column?

[d.cavestro]

I'd like to trigger a fetch when the user adds a visible column to the listgrid (sending the outputs metadata entry in order to obtain the - expensive to calculate - values even for that column).
So is there any way to intercept that change of visibility? (without rewriting the relevant header submenu). That way I could also intercept programmatic column addition/removals...

I'm using SmartGWT 3.0 - SmartClient Version: SC_SNAPSHOT-2011-12-05/LGPL Development Only (built 2011-12-05)

[Isomorphic]

FieldStateChanged fires in this situation.

[d.cavestro]

Solved

Many thanks.
Here you are the way I achieved it:

protected Set<String> visibleDynamicFields = new HashSet<String> ();
...
grid.addFetchDataHandler (new FetchDataHandler () {

    @Override
    public void onFilterData (FetchDataEvent event) {
        /*
         * add to server request data the list of visible fields
         */
        Criteria criteria = event.getCriteria ();
        JavaScriptObject data = event.getRequestProperties ().getData ();
        final String[] outputs = visibleDynamicFields.toArray (new String[0]);
        if (data != null) {
            JSOHelper.setAttribute (data, "outputs", outputs);
        } else {
            if (criteria != null) {//converts the criteria to map and adds "outputs"
                @SuppressWarnings ("unchecked")
                final Map<String, Object> dataMap = JSOHelper.convertToMap (criteria.getJsObj ());
                dataMap.put ("outputs", outputs);
                event.getRequestProperties ().setData (dataMap);
            }
        }
    }
});
grid.addFieldStateChangedHandler (new FieldStateChangedHandler () {

    @Override
    public void onFieldStateChanged (final FieldStateChangedEvent event) {
        final Set<String> actualFields = new HashSet<String> ();
        boolean hasNewFields = false;
        for (final ListGridField field : grid.getFields ()) {// for every visible field
            if (!visibleDynamicFields.contains (field.getName ())) {
                // there's at least a new visible field
                hasNewFields = true;
            }
            actualFields.add (field.getName ());
        }
        if (hasNewFields) {
            /*
             * there's a new visible field: invalidate local cache and force a fetch
             */
            setVisibleDynamicFields (actualFields);
            grid.getDataSource ().invalidateCache ();
            grid.invalidateCache ();
            grid.filterByEditor ();
        }
    }

});
...

Just my two cents for the community

[stonebranch1]

Thanks for posting.

I am looking at doing the same thing, informing the Server of the visible columns on the fetch request so that only the visible columns are retrieved with the caveat being that if the user changes the visible columns and add a column, it would cause a new fetch request.

I was just searching to see if the ListGrid had any API that did that automatically (request visible columns only).

Still researching this....

[Isomorphic]

There's a setting for this on ComboBoxItem/SelectItem (fetchDisplayedFieldsOnly) but not on ListGrid, because it's usually not a net optimization and has some subtle complexities.

It's often not a net optimization because the additional fields in Record, while not shown in the grid, could be displayed in a variety of ways, including hovers, expandable records, a related form or detailViewer. If the properties are not present, showing additional fields requires a new server fetch.

It has some complexity because you may have formatters, hover handlers or other logic that depends on the additional fields, so you'll need to make sure any such fields are present in the data even if hidden by the user.

If you think you might have a substantial net optimization here and you're prepared to deal with the complexity, what you want to do is set dsRequest.outputs via the requestProperties argument to fetchData().

This requestProperties only apply for a fetchData() call that results in a new ResultSet being created, so if you need to change them, first set data to an empty RecordList, then call fetchData() again.

[stonebranch1]

I understand completely yup. There is only one particular ListGrid that we have this scenario with. We can handle this one via the outputs as it is a special case in several different ways.

I am glad the outputs attribute exist since we can make good use of it for this Forest Gump ListGrid aka "special".

Thanks.