Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Common aspects

Each dynamic variable is identified by a unique name. Dynamic variables do not have a separate namespace. After evaluation, dynamic variables are handled like a static IzPack variable defined in a <variable> section. This means they are visible like any other IzPack variable for replacing placeholders or as default value for user input fields assigning a value to a variable. 

If the name of a dynamic variable is also used in a variable definition in the <variables> section it is always used to set a default value of the dynamic variable with the same name rather than unsetting it during refreshing if there are no further conditions matching in the <dynamicvariables> section for that variable.

An IzPack installer refreshes dynamic variables on each panel change, which subsequently might affect a whole chain of conditions from the <conditions> section depending on these variables.

It is possible to define a dynamic variable more times based on different conditions:

Example
<dynamicvariables>
  <variable name="thechoice" value="fallback value">
  <variable name="thechoice" value="choice1" condition="cond1">
  <variable name="thechoice" value="choice2" condition="cond2">
</dynamicvariables>

A dynamic variable behaves exactly like a "normal" IzPack variable with a static key-value pair if it has set the attribute checkonce="true" and an optional condition for its evaluation when it is evaluated.

It can be still overridden if there is another dynamic variable definition for the same key, which evaluates later based on a different condition.

A dynamic variable can lose it's value if as some point it cannot be evaluated from any of its definitions. It will be reinitialized with a value as soon as at least one of its definitions can be evaluated in some later phase.

Lifecycle states

The following lifecycle states are possible for a dynamic variable defined in the installer descriptor:

  • unset
    If unset, the variable is defined but does not have any active value and is invisible during the installation process.
  • set
    If set, the variable has an active value, which can be still changed during panel changes depending on changing variable conditions.
  • frozen 
    During being frozen, the variable value cannot be changed during refresh.

Precedence rules during refreshing

If a dynamic variable is defined multiple times with the same key, all definitions are applied during refreshing in the order they are defined in the <dynamicvariables> section. If all of the currently applicable definitions would unset the variable it is unset, otherwise the last definition in the list "wins" during refreshing.

Precedence rules between value changes during refreshing and user inputs

A dedicated dynamic variable is no longer refreshed if it has been assigned a value from a user input field. This means as soon as the user reaches a panel containing a field which overrides a variable with the same name as a dynamic variable by pressing Next, the dynamic variable enters the frozen state on entering the panel and remains there unless the user presses the Previous button and moves backward again over the corresponding panel. This means, a value entered by the user gets always precedence over values that would be generated by dynamic variable refreshing.

If there are more than one blocker panels that modify a dedicated variable, this variable is frozen immediately when passing the first one of them in order in case of pressing Next.
Vice versa, if there are more than one blocker panels that modify a dedicated variable, wait until passing the first one in order in case of pressing Previous for unblocking. 

If there the user presses Prev and there are no longer blocking UserInputPanels on a dynamic variable, the variable gets unfrozen and available for refreshing again.

Global precedence for dynamic variable assignments

As a result of what was described above, variable assignments happen with the following precedence:

  1. UserInputPanel field: A valid user input is assigned as a variable value and freezes the variable from further changes during refreshing.
  2. Refresh: try to get the last valid value in order of the definitions taking the conditions into account
  3. Refresh: try to find a default value from the <variables> section
  4. Refresh: unset if the variable value cannot be assigned due to no variable condition evaluating to true.

 

  • No labels