Groovy is an interpreted language for the JVM. Domains and DomEL use Groovy in the following ways:
• | The <principalExpression> tag in an access grant in the Domain Security file uses a Groovy expression to get the current authentication object and determine its access privileges, along with the user and roles associated with the object. In this case, Groovy is used directly inside the tag. See The Domain Security File for more information. |
• | You can use the DomEL groovy() function as part of a DomEL expression. The DomEl groovy function takes a single string argument that is interpreted as Groovy code. The output of the function is a string that is put into the SQL. To include Groovy, use the following syntax: |
groovy('your groovy code here')
• | For example, the following simple expression could be used to set the value of the calculated field e.groovyEval to the SQL string corresponding to the value of 5.0/6: |
<field id="e.groovyEval" dataSetExpression="groovy('(5.0/6).toString()')" type="java.lang.String" />
DomEL validation cannot check your Groovy code. You must ensure that any Groovy code meets these criteria, otherwise the expression causes errors when using the Domain to create a report.
Complex Expressions
Complex expressions are written by grouping any of the operators or functions above. Parentheses () may be used for grouping boolean operators, but arithmetic expressions that rely on parentheses are not supported. To compute complex arithmetic expressions, you may need to define several expressions as separate calculated fields, and then reference them in a simpler expression in another calculated field.
The following examples show complex expressions suitable for filters. This first one selects only stores in Western states of the US:
s1.store_country in ('USA') and s1.store_state in ('WA', 'OR', 'CA', 'NV')
The following filter expression uses a date range:
s1.first_opened_date in ( Date( '2000-01-01' ) : Date( '2004-12-31' )) and not( s1.closed )
As shown in these examples, field values are often compared to constant values such as 'USA'. Therefore, the author of the design file must ensure that values used in a DomEL expression exist in the data source. Otherwise, a wrong value might go undetected and impact the quality of data in reports based on the Domain. The Domain Designer determines values for comparison by accessing the data source, so if you export a design file, you can use the values it has found. Another way to reduce errors and also support future data changes is to use more general expressions such as:
s1.store_country in ('US', 'USA', 'United States')
Recommended Comments
There are no comments to display.