# Group workers and cache managers

When you have a colleciton of data, you want to be able to view that data from different perspectives.
To illustrate this, imagine you have a list of work order records, 100 of them.
When you view these records in a grid, you have data but not information, this only becomes useful information after you analyse the data to extract meaning from it.

We use a term called perspective to describe different angles of looking at data.
If I group the work orders by asset and do a count on those items I look at the data from the perspective of assets and how much work must be done on that asset.
If I gooup the work orders by staff and do a count I get a different perspective off the same origional data source.

Group workers allow us to massage data and gain different perspectives from that data.
The mechanisms we use to allow you to massage that data is through grouping, sorting and aggregate functions.

The first step in this process is to create a cache of the original "flat" data.
Once we have this cached, we can now create different perspectives by massaging the data.

This data massage process can be heavy processing and we need to ship it off to it's own thread. To this end we have a groupworker webworker.
In the root of pragma-views you will find the group-worker.js file. If your application requires this feature you will need to copy this file from the jspm folder of pragma views to the root of your project.

In the lib folder you will also find a group-worker.js file. This file is the ui thread counter part of the webworker. When communicating with web workers, the worker and caller post messages to each other.
The two group-worker.js files facilitate that process for you. If you need to create a cache or perspective, ask the group worker client library to do that for you.

## Group worker
One of the important things to know about the group worker is that it is completely fire and forget through the use of event aggregation.
The reason whey we use event aggregation here is that you may have multiple visualisations requiring updates from one perspective.
For example, I may have a grid and a chart, both rendering the same perspective, so if the perspective updates, both these visualisations need to be updated.
Event aggregation gives us a easy way to deal with this with out having tight coupling.

Actions exposed by the group worker are:

1. createCache - create a cache with a given name for a set or records
2. disposeCache - delete the cache and all it's perspectives
3. createGroupPerspective - create a perspective on a given cache
4. disposeGroupPerspective - delete the specified perspective
5. getGroupPerspective - retrieve the data of a given perspective
6. getRecordsFor - get the records for a perspective that applies a defined filter.

## Cache manger
The CacheManager uses the group worker. The schema defines perspectives but be used in visualizations like lookups and other generated views.
The cache manager understands the schema perspective structure and drives the group worker for dynamic forms.
