Examples of com.smartgwt.client.data.ResultSet

com.smartgwt.client.data.ResultSet
ResultSets are a subclass implementation of {@link com.smartgwt.client.data.RecordList} that automatically fetches DataSource records when items are requested from the List. ResultSets provide robust, customizable, high-performance cache management for ListGrids and other built-in SmartGWT components, and can be used as cache managers by custom components.
ResultSets manage data paging, that is, loading records in batches as the user navigates the data set. A ResultSet will switch to using client-side sorting and filtering when possible to improve responsiveness and reduce server load. ResultSets also participate in automatic cache synchronization, observing operations on DataSources and automatically updating their caches.
Creation
A ResultSet can be passed to any component that expects a List, and the List APIs can be called directly on the ResultSet as long as the caller is able to deal with asynchronous loading; see {@link ResultSet#getRange}.
Generally ResultSets do not need to be created directly, but are created by DataBound components as an automatic consequence of calling {@link com.smartgwt.client.docs.DataBoundComponentMethods 'DataBound Component Methods'}. For example, the {@link com.smartgwt.client.widgets.grid.ListGrid#fetchData} causes {@link com.smartgwt.client.widgets.grid.ListGrid#getData data} to become an automatically created ResultSet object. Automatically created ResultSets canbe customized via properties on ListGrids such as {@link com.smartgwt.client.widgets.grid.ListGrid#getDataPageSize dataPageSize} and {@link com.smartgwt.client.widgets.grid.ListGrid#getDataProperties dataProperties}. All ResultSets for a given DataSource may also be customized via setting {@link DataSource#getResultSetClass resultSetClass} to the name of a ResultSet {@link com.smartgwt.client.util.isc#defineClass} in which {@link com.smartgwt.client..Class#addProperties}.
A ResultSet defaults to using data paging, setting {@link DSRequest#getStartRow startRow}and {@link DSRequest#getEndRow endRow} in issued dsRequests. Server code may alwaysreturn more rows than the ResultSet requests and the ResultSet will correctly integrate those rows based on {@link DSResponse#getStartRow startRow}/ {@link DSResponse#getEndRow'endRow'}. Hence the server can always avoid paging mode by simply returning all matching rows.
A ResultSet can be created directly with just the ID of a {@link DataSource}:
```
 isc.ResultSet.create({
         dataSource : "dataSourceID"
     })
 
```
Directly created ResultSets are typically used by custom components, or as a means of managing datasets that will be used by several components.
When created directly rather than via a dataBoundComponent, a newly created ResultSet will not issue it's first "fetch" {@link DSRequest} until data is accessed (for example,via {@link ResultSet#get}).
Paging and total dataset length
When using data paging, the server communicates the total number of records that match the current search criteria by setting {@link DSResponse#getTotalRows totalRows}. The ResultSet will then return this number from {@link ResultSet#getLength}, and ListGrids and other components will show a scrollbar that allows the user to jump to the end of the dataset directly.
However, the ResultSet does not require that the server calculate the true length of the dataset, which can be costly for an extremely large, searchable dataset. Instead, the server may simply advertise a totalRows value that is one page larger than the last row loaded. This results in a UI sometimes called "progressive loading", where the user may load more rows by scrolling past the end of the currently loaded rows, but is not allowed to skip to the end of the dataset.
No client-side settings are required to enable this mode - it is entirely server-driven. However, it is usually coupled with {@link com.smartgwt.client.widgets.grid.ListGrid#getCanSort 'disabling sorting'}, since server-side sorting would also force the server to traverse the entire dataset.
Client-side Sorting and Filtering
If a ResultSet obtains a full cache for the current set of filter criteria, it will automatically switch to client-side sorting, and will also use client-side filtering if the filter criteria are later changed but appear to be more restrictive than the criteria in use when the ResultSet obtained a full cache.
The {@link ResultSet#getUseClientSorting 'useClientSorting'} and {@link ResultSet#getUseClientFiltering 'useClientFiltering'} flags can be used to disable client-side sorting and filtering respectively if these behaviors don't match server-based sorting and filtering. However, because client-side sorting and filtering radically improve responsiveness and reduce server load, it is better to customize the ResultSet so that it can match server-side sorting and filtering behaviors.
Sorting behavior is primarily customized via the "sort normalizer" passed to {@link ResultSet#sortByProperty}, either via direct calls on a standalone ResultSet, or via {@link com.smartgwt.client.widgets.grid.ListGridField#sortNormalizer} for a ListGrid-managed ResultSet.
Bydefault, client-side filtering interprets the {@link Criteria} passed to {@link ResultSet#setCriteria} as a set of field values that records must match (similarly to thebuilt-in SQL/Hibernate connectors built into the SmartGWT Server). Custom client-side filtering logic can be implemented by overriding {@link ResultSet#applyFilter}. Overriding {@link ResultSet#compareCriteria} allows you to control when the ResultSet uses client-side vsserver-side filtering, and the ResultSet has two default {@link ResultSet#getCriteriaPolicy 'criteria policies'} built-in.
Updates andAutomatic Cache Synchronization
ResultSets observe any successful "update", "add" or "remove" dsRequests against their DataSource, regardless of the component that initiated them. A ResultSet with a full cache for the current filter criteria will integrate updates into the cache automatically.
Updated rows that no longer match the current filter criteria will be removed automatically. To prevent this, you can set {@link ResultSet#getNeverDropUpdatedRows neverDropUpdatedRows}. Added rows will similarly be added to the cache only if they match current filter criteria.
Note that the client-side filtering described above is also used to determine whether updated or added rows should be in the cache. If any aspect of automated cache update is ever incorrect, {@link ResultSet#getDropCacheOnUpdate'dropCacheOnUpdate'} can be set for the ResultSet or {@link DSResponse#getInvalidateCache invalidateCache} can be set for an individual dsResponse.
Data Paging with partial cache
When in paging mode with a partial cache, a ResultSet relies on server side sorting, setting {@link DSRequest#getSortBy sortBy} to the current sort field and direction. In order for the cache to remain coherant, row numbering must continue to agree between server and client as new fetches are issued, otherwise, duplicate rows or missing rows may occur.
If concurrent modifications by other users are allowed, generally the server should set {@link DSResponse#getInvalidateCache invalidateCache} to clear the cache when concurrent modification is detected.
In paging mode with apartial cache, any successful "update" or "add" operation may cause client and server row numbering to become out of sync. This happens because the update may affect the sort order, and client and server cannot be guaranteed to match for sets of records that have equivalent values for the sort field.
For this reason, after an "add" or "update" operation with a partial cache, the ResultSet will automatically mark cache for invalidation the next time a fetch operation is performed. Alternatively, if {@link ResultSet#getUpdatePartialCache updatePartialCache} is set to false, the ResultSet will simply invalidate cache immediately in this circumstance.

    private void refreshRowCount() {
        Label tableInfo = getTableInfo();
        if (tableInfo != null) {
            boolean lengthIsKnown = false;
            if (listGrid != null) {
                ResultSet results = listGrid.getResultSet();
                if (results != null) {
                    Boolean flag = results.lengthIsKnown();
                    if (flag != null) {
                        lengthIsKnown = flag.booleanValue();
                    }
                } else {
                    lengthIsKnown = (listGrid.getDataSource() == null); // not bound by a datasource, assume we know

View Full Code Here

        });
        if (canSupportDeleteAndAcknowledgeAll()) {
            addTableAction(MSG.common_button_ack_all(), MSG.view_alerts_ack_confirm_all(), new TableAction() {
                public boolean isEnabled(ListGridRecord[] selection) {
                    ListGrid grid = getListGrid();
                    ResultSet resultSet = (null != grid) ? grid.getResultSet() : null;
                    return (hasWriteAccess && grid != null && resultSet != null && !resultSet.isEmpty());
                }


                public void executeAction(ListGridRecord[] selection, Object actionValue) {
                    acknowledgeAll();
                }
            });
        }


        addTableAction(MSG.common_button_delete(), MSG.view_alerts_delete_confirm(), ButtonColor.RED,
            new ResourceAuthorizedTableAction(AlertHistoryView.this, TableActionEnablement.ANY, (hasWriteAccess ? null
                : Permission.MANAGE_ALERTS), new RecordExtractor<Integer>() {
                public Collection<Integer> extract(Record[] records) {
                    List<Integer> result = new ArrayList<Integer>(records.length);
                    for (Record record : records) {
                        result.add(record.getAttributeAsInt("resourceId"));
                    }
                    return result;
                }
            }) {


            public void executeAction(ListGridRecord[] selection, Object actionValue) {
                delete(selection);
            }
        });
        if (canSupportDeleteAndAcknowledgeAll()) {
            addTableAction(MSG.common_button_delete_all(), MSG.view_alerts_delete_confirm_all(), ButtonColor.RED,
                new TableAction() {
                public boolean isEnabled(ListGridRecord[] selection) {
                    ListGrid grid = getListGrid();
                    ResultSet resultSet = (null != grid) ? grid.getResultSet() : null;
                    return (hasWriteAccess && grid != null && resultSet != null && !resultSet.isEmpty());
                }


                public void executeAction(ListGridRecord[] selection, Object actionValue) {
                    deleteAll();
                }

View Full Code Here


        addTableAction(MSG.common_button_delete_all(), MSG.view_drift_confirm_deleteAllDefs(), ButtonColor.RED,
            new TableAction() {
            public boolean isEnabled(ListGridRecord[] selection) {
                ListGrid grid = getListGrid();
                ResultSet resultSet = (null != grid) ? grid.getResultSet() : null;
                return (hasWriteAccess && grid != null && resultSet != null && !resultSet.isEmpty());
            }


            public void executeAction(ListGridRecord[] selection, Object actionValue) {
                deleteAll();
            }

View Full Code Here

TOP

Related Classes of com.smartgwt.client.data.ResultSet

com.google.gwt.core.client.JavaScriptObject

org.rhq.coregui.client.alert.AlertHistoryView

org.rhq.coregui.client.components.table.Table

org.rhq.coregui.client.drift.DriftDefinitionsView

All source code are property of their respective owners. Java is a trademark of Sun Microsystems, Inc and owned by ORACLE Inc. Contact coftware#gmail.com.