Literal projection
Projection – Abstract
Purpose: Returns a simple fixed value in the context of a search.
A Literal projection returns a fixed value in the context of a search, determined solely by the value configuration for the Literal parameter.
The Literal projection is frequently (and often repeatedly) used in the context of a Concatenated projection to contribute static components to a concatenated text.
Configuration
|
Parameter |
Type |
Description |
|
Name |
String |
The optional Name parameter can be used to assign an (alias) name to the projection.
|
|
Literal |
undefined |
The value configuration determines a return value, which is determined once and enters as a constant in the execution of the query on the database.
By default, a text value resolver (see Static values) is suggested, since returning a string is the most common use for a static value. Technically, any value resolvers (individually or in combination, see Chained resolver) can be used to define a Literal. However, not all data types are suitable as return values for a Literal.
|
Examples
Typical example: Text concatenation with static components
The Literal projection is used particularly often to combine field contents with static text characters in a Concatenated projection of a CSV or tuple search.
In the following example, in a search on the City entity, a reference to the 'State' (state) is enclosed in brackets and then attached to the place name (placeName).
|
The screenshot shows a Concatenated projection with four text components:
►NOTE◄ All projections used here do without a specification for the Name parameter. Effectively, the column name for the Concatenated projection is therefore systematically composed from the default names for the concatenated projections. The literals contribute the complete Literal. Runtime example: placeName (state) Neukirchen (Oberösterreich) |
|
Simple example: Write a number range value into the query result
Each time a search is called, a unique string is generated via a Number range value resolver, which on one hand identifies the executing user (User of session) via his ID (id) and on the other contains a 'sequence number' for the query.
Configuration:
►NOTE◄ In order for a Literal projection to appear in the search result, a tuple or CSV search must be performed. In the example, we assume a CSV search for an unspecified entity.
|
The screenshot shows three Projections for the (CSV) search, the first of which – a Literal projection – is shown expanded:
The other projections with the (alias) names 'Booking' and 'Status' contain the actual payload of our request. |
|
Runtime example:
|
First CSV search request |
Subsequent CSV search request |
Search_ID,Booking,Status USR:1901#QRY:1000007,RE01230858,NEW |
Search_ID,Booking,Status USR:1901#QRY:1000009,RE01230859,NEW |
The second run results in changed status values for some bookings and an additional new booking compared to the first one.
Simple example: 'Recoding' a Boolean value (e.g. to plain text)
Fields with Boolean values can be used to binarily assign or deny qualitative characteristics to an entity. In a direct projection for such a field, a Boolean value (true/false) then appears in each case, without it being apparent when looking at an output line what this should actually mean.
The 'readability' of the data in a search result can then be increased by assigning a text identifier describing the presence or absence of the flagged feature instead of the Boolean value in each output line.
In the following very simple case, the status of a user account (see Users) is 'recoded' as plain text using the 'Active' (active) Boolean field in a projection, so that the text 'ACTIVE' or 'INACTIVE' appears.
Configuration:
►NOTE◄ In order for a Literal projection to appear in the search result, a tuple or CSV search must be performed. In the example, we assume a CSV search for the 'User' (User) entity.
|
The screenshot shows two Projections for the output of a list of user accounts with a clear indication whether the respective account is active ('ACTIVE') or not ('INACTIVE'):
|
|
Runtime example:
|
In the result of the CSV search, the ACCOUNT_STATUS column shows in an immediately understandable way whether the respective account is active or not. The output of true/false would only be understandable in connection with the column name. |
ACCOUNT_STATUS,ACCOUNT_NAME ACTIVE,mjmartinez123 |
Special use: Literale Projektion as a check value in a Field restriction
Configuration:
|
The screenshot shows the configuration for the Restriction of a custom overview for Company accounts accounts based on an OR operation of two instances of the Field restriction:
|
|
ALTERNATIVE configuration:
|
The configuration shown on the right solves the task equally but a bit more elegantly:
►NOTE◄ Using the Rule value resolver, any rules can be included in the Restriction according to this scheme, which enables, among other things, access to Association criteria as a Sub criterion rule. However, it must be taken into account that the return values of rules come into play this way only as constants, they cannot be applied to fields of the entity searched for or evaluated in its context. If, on the other hand, a Property projection returns a check value from a Boolean field of the entity searched for, for example, this can be contrasted with a Boolean compare value from a Rule value without this having to be 'packed' (on the right-hand side in the comparison) into a Literal projection for this purpose. |
|
