Page History
...
| Element type | Type name | Explanation |
|---|---|---|
| FlowType | FreeFlow | The main flow which to detect if an application should to be using the free navigable strategy |
| FlowType | Sub flows of the FreeFlow to which the user can navigated between. Each SinglePageFlow will become a menu item. | |
| ContainerType | The menu container which displays menu-items for with the name using the page display title of the first page of in the SinglePageFlow | |
| ContentStyle | NavigationMenu | Default contentstyle of the AQ_NavigationMenu container |
...
Inside the FreeFlow itself, or one of its sub flows, a connected group of SinglePageFlows can be modelled to create a free navigable flow. These SinglePageFlows act as the entry points of navigation actions. It is advised to not have any logic flow actions in between the SinglePageFlows other than condition nodes.
When navigating between SinglePageFlows by using the navigation actions, the flow that connects the SinglePageFlows is not used, the Runtime jumps between the SinglePageFlows. If logic is required flow actions are necessary make sure that it they either resides reside in the SinglePageFlow (as it they will be executed every time the flow is visited) or before first SinglePageFlow and after the last SinglePageFlow.
...
The navigation menu of a free navigable flow is build built by using the name display title of the first page page in a SinglePageFlow. For the navigation menu to be displayed, the pages of a SinglePageFlow should contain a AQ_NavigationMenu container. Navigating in a free navigable flow can be achieved via two ways:
- Using the sequentially modelled next button to navigate to the next SinglePageFlow
- Using the menu items in navigation menu to switch to an other SinglePageFlow
The order of the SinglePageFlows determines the ordering of the navigation menu. In case that a branch of SinglePageFlows is behind a condition node and it evaluates to false the whole branch is still displayed but disabled in the navigation menu, once the condition becomes true the branch is navigable from the navigation menu.
A free navigable flow still allows the user to navigate the flow sequentially from SinglePageFlow to SinglePageFlow. To achieve this each first page of the SinglePageFlow must contain a button with either no event attached to it, or and an event with the name "NextPage". This button event should connect to the EndNode of the SinglePageFlow or a non-interactive FlowNode which leads to the EndNode. In order to navigate to the previously visited page a button can be placed on the page with the event "PreviousPage", this button does not need to be connected.
...
| Info | ||
|---|---|---|
| ||
Model breaking errors like invalid inputs e.q. filling a String value into a Number field are this still blocked. |
Constraints
The new navigation concept is introduced as Runtime concept, that is triggered by a specific model structure and naming convention.
- The exposed flow must be of type FreeFlow.
- The SinglePageFlows should be directly connected to each other inside a free navigable flow.
- The FreeFlow can contain other flow types before entering of the first SinglePageFlow, and after the last SinglePageFlow but not in between SinglePageFlows.
- All validations on pages modelled in SinglePageFlows become non-blocking validation errors.
- The name display title of the first page of a SinglePageFlow will be used to populate the AQ_NavigationMenu container.
- The AQ_NavigationMenu container should always be modelled in the first page of the SinglePageFlow, or it will not be displayed.
- Condition nodes modelled in between SinglePageFlows will acts as preconditions for buttons that make up the AQ_NavigationMenu container.
- The SinglePageFlow's first page default (empty) or "NextPage" button event must be connected to an EndNode or an non interactive FlowNode that leads to an EndNode
Overview
Content Tools