Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

This page outlines the options available for setting up global filtering of data.

Weave 2.6.10 adds support for setting up filters that can be applied to a number of different configuration items allowing a user to work with a sub-set of the data that the administrator has provided them access to.

For example, if a user wanted to work with trees that were last inspected in a specific year the administrator can setup a filter definition that would allow the user to enter the year and then update the configurations for any data definitions, attribute searches, map engines, etc, that are related to trees to have them use the information provided by the user for the filter to refine what information is included in those items. Then any attribute searches performed will only search for data within the year range, then map would only display trees within the date range, and grids will only show rows for the year range, etc.

Using data filters relies on “user attributes” and requires two parts to setup. User attributes are a concept in Weave where custom attributes can be associated with a user and then referenced in configuration files, allowing for per-user customisation. By adding the ability for the client to set custom user attributes and ensuring the appropriate Weave configuration items can make use of those attribute to perform filtering Weave 2.6.10 make it possible for the administrator to provide the user with the ability to perform dynamic filtering.

Defining a filter

For an end user to be able to enter the information required to apply a filter a filter definition must be created. The filter definition specifies what values can be used to filter the underlying data, in the example below we are just filtering on the inspection date, but the filter can contain multiple unrelated (unrelated to each other, not unrelated to the trees) parameters to filter on things other than inspection date, for example on the tree species.

<?xml version="1.0" encoding="UTF-8"?>

<config xmlns="urn:com.cohga.server.config#1.0" 
	xmlns:dynamicattributes="urn:com.cohga.weave.dynamic.attributes#1.0">

	<dynamicattributes:config id="trees">
		<label>Trees</label>
		<parameter name="insp_date" label="Insp. Date" controlType="date" dataType="date"/>
	</dynamicattributes:config>

</config>

The filter definition like the one above describes what values can be set and is used to present the end user with a form where they can enter the values. Once the user enters values they are sent to the server and saved as dynamic user attributes, but they don’t actually filter anything at this stage. To perform filtering based on the dynamic user attributes the attributes need to be referenced in the configuration for the things that the administrator would like the filter to apply to, like a data definition, or attribute search, etc.

Using a filter

To apply a filter to another item in Weave the item would need to support filtering in the first place, you should refer to the configuration wiki page for the particular item to see if it supports filtering.

For example, if you wish to apply the filter to a data definition that uses a database table to retrieve data then the filter can be added as an SQL Where clause in the data definition configuration. This is possible because the dayasourcedataconnection type of data definition provides support for filtering using SQL via the where tag, where-as an inlinedataconnection does not (currently) support filtering so cannot use a dynamic user attribute to refine the returned data.

<?xml version="1.0" encoding="UTF-8"?>

<config xmlns="urn:com.cohga.server.config#1.0" 
	xmlns:data="urn:com.cohga.server.data.database#1.0">

	<data:datadefinition id="trees">
		<datasourcedataconnection datasource="database" table="trees" key="id" prefix="DISTINCT">
			<where clause="insp_date = ${user.dynamic.trees.insp_date}"/>
			<parameter type="string" name="species" label="Species" column="species"/>
			<parameter type="string" name="location" label="Location" column="location"/>
			<parameter type="date" name="insp_date" label="Insp. Date" column="insp_date"/>
		</datasourcedataconnection>
	</data:datadefinition>

</config>

You can see in the above example an additional where clause has been added to the configuration that will filter the rows returned from the SQL based on the insp_date column in the table matching the value entered by the user. Note that if the user has not given a value for the insp_date value then the where clause will not be applied and all rows will be returned from the table that match the current selection (since there are no other where clauses defined in the configuration).

The values the user enters for the filter are referenced using the format:
${user.dynamic.<filterid>.<parameterid>}
and in some situation the value set for the filter parameter may require coercion to convert it to the format required by the underlying provider (e.g. database, spatial engine, etc), for example some databases may require a CAST or CONVERT function to wrap the value provided by the filter to ensure it is in the format that the database requires. Take note that since this is new functionality there may also be issues with the conversions that should be, or even need to be, handled by Weave, so if you’re having issues getting a particular dynamic user attribute to with contact support for help.

The above example configuration just applies the filter to a single data definition associated with the trees but in all likelihood you will have additional configuration items which would also make sense to have the filtering applied to, for example you could apply the filter to the spatial mapper for the trees entity so that when a user tries to select a tree spatially with one of the map selection tools only those trees that meet the filter restrictions would be selected. 

<?xml version="1.0" encoding="UTF-8"?>

<config xmlns="urn:com.cohga.server.config#1.0" 
	xmlns:mapper="urn:com.cohga.server.spatial.mapper#1.0">

	<mapper:mapper id="trees">
		<spatialEngine>spatialengine</spatialEngine>
		<mapping>
			<entity>trees</entity>
			<table>trees</table>
			<key>id</key>
			<filter>insp_date = ${user.dynamic.trees.insp_date}</filter>
			<dynamic>true</dynamic>
			<cache>false</cache>
		</mapping>
	</mapper:mapper>

</config>

Or you could apply the filter to the map engine that displays the trees so that only the trees that meet the filter criteria will be drawn on the map. 

<?xml version="1.0" encoding="UTF-8"?>

<config xmlns="urn:com.cohga.server.config#1.0" 
	xmlns:filter="urn:com.cohga.weave.map.filter#1.0">

<!-- currenty map layer filters are not defined directly in the map engine itself
but are a separate configuration item in their own right.
In this case we're creating a user map layer filter and referencing the dynamic user attribute -->
	<filter:user id="trees">
		<mapengine>mapengine</mapengine>
		<layer>trees</layer>
		<filter>insp_date = ${user.dynamic.trees.insp_date}</filter>
	</filter:user>

</config>

A filter can also be applied to attribute searches.

<?xml version="1.0" encoding="UTF-8"?>

<config xmlns="urn:com.cohga.server.config#1.0" 
	xmlns:search="urn:com.cohga.server.search.database#1.0">

	<search:attribute id="trees">
		<entity>trees</entity>
		<label>Trees</label>
		<description>Locate a tree</description>
		<datasource>database</datasource>
		<table>trees</table>
		<key>id</key>
		<where clause="insp_date = ${user.dynamic.trees.insp_date}"/>
		<parameter id="species" label="Species" column="species" dataset="tree.species"/>
		<parameter id="location" label="Location" column="location" dataset="tree.locations"/>
		<parameter id="insp_date" label="Insp. Date" column="insp_date" controltype="date"/>
		<cache disable="true"/>
	</search:attribute>

</config>

Note that the above search includes a search parameter for the inspection date and also uses the user attribute for filtering, this is to allow the user to still be able to select from all trees based on inspection date when no filtering is currently being applied, but this can result in nothing being found if the filtering is applied and the user enters different values for the two inspection dates, since the where clauses will be combined using an AND is the SQL statement and results in a where clause that will return nothing, e.g. WHERE insp_date = 2023-01-05 AND insp_date = 2023-01-06.

By applying the filtering to each item that’s related to the trees then end user will have a consistent filtered view of the data related to the values they entered for the filter, which is the intended use case of thing functionality.

  • No labels