Templates and Reports

Infomaptic allows you to author templates. Each template has a data source assigned to it. When the template is converted into a Report, a single record is extracted from the data source (via the URL parameter key) and used to populate the data.

In some sense the formula for a report looks like this:

Report = Template + Record

Really a Report is built by combining a Template and a Record from a Data Source, so a better representation of it might be:

It might help to explain this in terms of an equation, something like this:

Report = Template + OneRecord(Data Source)

But to really understand what happens here, we need to define the function OneRecord. Fortunately you do that when you define the where-clause associated with the Data Source in the Template. The where-clause that you specify should resolve a single record out of the Data Source, usually based on the query parameter key.

The default where-clause is built using the ObjectID field of the Data Source, and usually looks something like this:

'ObjectId = ' + data.key.value

Which is actually just an Atelerix expression, so you can build any where-clause that you like here*.

The variable data.key.value resolves to the value that is specified in the URL Query parameter key. This makes it easy for you to build a custom OneRecord function by controlling how that key value is used within the where-clause.

Most of the time, the ObjectId default will suffice just fine. You just specify the record you want by its ObjectId. For example, in the Portland Area Farmer’s Markets example, the where-clause is:

'OBJECTID = ' + data.key.Value

So if I wanted to load the Market called “Montavilla Farmers Market” I just need to know what ObjectID to use, in this case it’s 3, so I can construct the URL as:

https://app.infomaptic.com/viewer/f5a7452cbd434a7293ec2ed56f61058b?key=3

Which will create the where-clause:

'OBJECTID = 3'

Pretty convenient!

Note: You can see how the where-clause and the URL key interact using the Publish Screen.

* Within reason anyway. We actually do a little processing to that data.key.value to ensure that any SQL Injection type attacks stay out. We don’t want users to be able to alter the where-clause by crafting a special key value. You can see more in our blog post Oh No! SQL Injection!.