...
Conditions are defined in the installation definition as nested <condition>
elements of the <conditions/>
element.
Foe For example:
...
The following attributes must be set in a <condition> element definition:
Attribute | Usage |
---|---|
| The type of the condition. For built-in types, this is the lowercase portion of the condition class name without condition appended (variable,packselection,java, ...). Custom condition types should be referenced by the full qualified class name, e.g. de.dr.rules.MyCoolCondition. |
| The id of the condition. This will be used to refer to this conditions in other elements |
<condition> - Nested Elements
...
Code Block | ||
---|---|---|
| ||
<conditions> <condition type="variable" id="standardinstallation"> <name>setup.type</name> <value>standard</value> </condition> <condition type="variable" id="expertinstallation"> <name>setup.type</name> <value>expert</value> </condition> <condition type="java" id="installonwindows"> <java> <class>com.izforge.izpack.util.OsVersion</class> <field>IS_WINDOWS</field> </java> <returnvalue type="boolean">true</returnvalue> </condition> <condition type="and" id="standardinstallation.onwindows"> <condition type="ref" refid="standardinstallation"/> <condition type="ref" refid="installonwindows" /> </condition> </conditions> |
Anchor | ||||
---|---|---|---|---|
|
Conditions are referenced as optional attributes of several other elements in a installation definition or from IzPack resources:
...
Referencing A Number Of Conditions In One Expression
Anchor | ||||
---|---|---|---|---|
|
From IzPack 3.11 on, you don't have to define compound conditions because you can use a simple expression language. The language supports the following operators:
+ | an operator for the |
&&
And Condition | |
| an operator for the |
Or Condition |
||
| an operator for the |
Xor Condition | |
| an operator for the Not Condition |
These simple expressions DO NOT follow the usual boolean logic with precedence rules. Instead, they are evaluated left to right in a simple way.
Example:
Code Block |
---|
{{\!conditionA+conditionB+\!conditionC}} |
does not equal
Code Block |
---|
{{(\!conditionA) && conditionB && (\!conditionC)}} |
but is the same like
Code Block |
---|
{{\!(conditionA && (conditionB && \!(conditionC)))}} |
Example:
Code Block | ||||
---|---|---|---|---|
| ||||
<dynamicvariables> <variable name="db.instance" value="MSSQLSERVER" checkonce="true" condition="useMssql+mssqlInstanceSelected+!haveDatabaseURL" /> </dynamicvariables> |
...
Anchor | ||||
---|---|---|---|---|
|
Beginning with IzPack 5.0, there is also the possibility to use a more complex expression language which evaluates based on boolean precedence rules, which is also reflected in the following table. The higher an operator is, the higher is its precedence.
^ | an operator for the |
|
Xor Conditon | |
| an operator for the |
And Condition |
^
| an operator for the |
Or Condition | |
| an operator for the Not Condition |
Example:
Code Block |
---|
{{@!conditionA+&&conditionB+&&!conditionC}} |
equals
Code Block |
---|
{{(!conditionA) && conditionB && (!conditionC)}} |
In order to use the complex expression language the expression must start with a '@
' character.
Example:
Code Block | ||||
---|---|---|---|---|
| ||||
<dynamicvariables> <variable name="db.instance" value="MSSQLSERVER" checkonce="true" condition="@useMssql && !haveDatabaseURL && mssqlInstanceSelected" /> </dynamicvariables> |
Note |
---|
Because "&" is a reserved character in xml documents you have to use "&" instead! |