Filters are set by the filters dialog. For each column of a valid type (as listed above), the user can define a filter. A filter on a column is an expression. A filter expression can be either made up of AND-subexpressions or OR-subexpressions. If there exist more than one column with an filter, the filter expressions are joined with the AND operator.

Example. The user wants to a list of persons whose first name is equal to ("John" or "Frank") AND whose birthdate is before 1.1.1985:

All this can also be modeld in dsl. There is a little more information needed in your .pml file. To enhance our previous example with the tableCustomizer you would have to update the above modeling file in the following way:

style pagingTable {
    table-customizer : testTableCustomizer
    paging-customizer-image : "/org/openxma/demo/customer/xma/client/cog_go.png"
    paging-position : top
    paging-style : custom
    paging-jump-size : 10
    paging-page-size : 10 max = 1000
    paging-controls : back, customize, pagesize, next, fastnext, fastback, info, reload, start, end
}

tablecustomizer testTableCustomizer instancetype org.openxma.addons.ui.^table.customizer.^xma.client.ITableCustomizer

The new lines are marked bold: First you define a unique name for the tableCustomizer. Next, optionally you can specify an image that is used on the pagingControl for the button used to invoke the tableCustomizer dialog. Of course the image has to exist in your projects artifact in the specified path. And last you have to specify which TableCustomizer to use for the pagingControl.

The implementation classes for the customizer interface are not included in the default project classpath. So if you want tu use the tableCustomizer the projects classpath and your build must be extended.

Using the TableCustomizer means that queries used at the backend to display data can change at runtime, depending from the filter settings applied in the TableCustomizer Dialog. So these "filterable queries" have to be defined in the persistance model (dml), since queries are not filterable by default.

You can define filterable queries like this:

repository CustomerDao for Customer {
    table = "T_CUSTOMER"
    operation Customer[] findCustomers() : from Customer as customer
}

service CustomerDas {
    CustomerDao.crud
    CustomerDao.findCustomers 
     filter=true 
}

Caution: Do not use filter=true on operations that already have a order by-clause! This can lead to erroneous HQL-queries. Initialize the sort order in the presentation layer, if you want to predefine the sort order of the table data.

public QueryObject getCustomerTableQueryObject() {
         int offset = customerTable_pagingControl.getOffset();
         short pageSize = customerTable_pagingControl.getPageSize();
         short sortingColumn = customerTable_pagingControl.getSortingColumn();
         boolean isAscending = customerTable_pagingControl.getAscending();
         XMASessionServer xmaSessionServer = (XMASessionServer)XMASessionServer.getXMASession();
         ITableCustomizerServer tableCustomizer = (ITableCustomizerServer)xmaSessionServer.getComponent(Short.valueOf(customerTable_customizerComponentId.getEncodedValue()));
         QueryObject filterQueryForTable = null;
         if (sortingColumn >-1) {
             filterQueryForTable = tableCustomizer.getQueryObject(sortingColumn,isAscending);
         } else {
             filterQueryForTable = tableCustomizer.getQueryObject();
         }
         filterQueryForTable.setFirstResult(offset);
         filterQueryForTable.setMaxResults(pageSize);
         return filterQueryForTable;
}

As you can see, the code uses the paging control information: offset, pageSize, and sorting information is read to set up dynamically a generic filter query for the CustomerTable. The returned QueryObject is actually the filter that has to be passed to the query as parameter. The invokation of the query itself has to be done manually and the best place to do so is the remote method that was defined in the model to react on the UI navigation events:

@Override
public void loadData(RemoteCall call, RemoteReply reply) { 
 Collection<CustomerView> findCustomers = null;
 QueryObject queryObject = getCustomerTableQueryObject();
 findCustomers = getTypedComponent().customerDas.findCustomers(queryObject);
 getTypedComponent().setCustomers(findCustomers);
 customerTableFill();
}

In the above sample implementation for the loadData remote call, the previously defined filter query "findCustomers" is invoked and the filter that was retrieved from the generated method getCustomerTableQueryObject() is passed as parameter.

The configuration can be expressend in the style information for the paging control with the export-keyword:

style pagingTable {
    table-customizer : testTableCustomizer
    paging-customizer-image : "/org/openxma/demo/customer/xma/client/cog_go.png"
    paging-position : top
    paging-style : custom
    paging-jump-size : 10  
    paging-page-size : 10 max = 1000
    paging-controls : back, customize, pagesize, export, next, fastnext, fastback, info, reload, start, end
}

On export, the CSV-File will be saved to the default directory for temporary files (using the default encoding of the client VM) and opened with the default handler associated with CSV-Files. Be aware, that encoding problems may occur in Microsoft Excel if the default encoding is different to windows-1252!

In the serverside page there is an abstract method generated that must be implemented manually. The implementor is asked here to provide the collection that is used as input for the .csv table export. The name of the abstract method is built based on the table name: queryFor<tableName>ExportData(QueryObject queryObject). Take care to provide the right collection - it should correlate with the filter query used to display the table data:

@Override
public Collection<?> queryForCustomerTableExportData(QueryObject queryObject) {
    return getTypedComponent().customerDas.findCustomers(queryObject);
}

@Override
protected int getCustomerTableExportBatchSize() {
    return 1000;
}

Observe: Be sure to comply with the given boundries in QueryObject at server side, or endless loops may occur.