The view to be opened can be addressed in two different ways:

1. If static text is specified for the View or menu node name parameter, the system searches for a view or menu node with the specified name. In this case, the input value ($input) can be used for the 'Data assignment' (see below) to the view (see top right: 'Static definition...').
   
   

2. If no text is specified for the View or menu node name parameter, a view or menu node name is expected as an input value ($input). The form data is then used for the data assignment – taking into account the 'Data field' parameter if necessary (see below right: 'Dynamic definition...').

►NOTE◄ If the View or menu node name is handled in a variable way at runtime (e.g. via Calculate behaviour), only the second option is possible. The View or menu node name parameter itself does not interpret any calculation expressions.

A view is only opened if:

1. The specified string corresponds exactly to an existing menu node name or view name,

2. There are sufficient authorizations for the role used

3. At least one relevant configuration for the relevant context is assigned at runtime, if applicable (see Association criteria, Company authorizations).

Whether the following example values work as View or menu node names also depends in part on which Lobster_pro modules are licensed:

• documentation ... opens the Handbuch via menu node name.
  

• documents

  • Opens an overview for Dokumente via menu node name.

• de.lobster.scm.doc::Document|listDetailsWindow

  • Opens the same overview via view name.
    

• order/orderDetails

  • Opens an input form for Bestellungen via menu node name.

• de.lobster.scm.order.bto::Order|detailsWindow

  • Opens the same overview via view name.

• Portal$SELECT_PORT

  • Opens a portal with the internal name SELECT_PORT via view name.

• dashboard$KPI2020

  • Opens a dashboard with the internal name KPI2020 via view name.

Static definition of the view to be opened

The view name for the input form for Users is defined as static text:

• de.lobster.scm.base.security.user::User|detailsWindow

Dynamic definition of the view to be opened

The view name is constructed using a Calculation expression in a Calculate behaviour so that Open view (Action) opens an input form for Users or for Guest users depending on the value of a Check box element (here: $el(11)). The 'calculated' text section is highlighted in the following view names:

• de.lobster.scm.base.security.user::User|detailsWindow

• de.lobster.scm.base.security.guest::GuestUser|detailsWindow

►IMPORTANT◄ The input value is only taken into account as a View or menu node name if there is no static text for the parameter itself..

If a view cannot be opened, no error (process exception) occurs so that subsequent actions and behaviours are executed. However, this does not apply to an optional follow-up process triggered by Execute behaviour after closed. This does not apply if no view is opened, because then no view is closed.

How can I determine the view name and the menu node name?

The view name and menu node name of a view that is already open can be determined by clicking on the ?-symbol at the top right of the window title while holding down the key combination STRG+ALT (or. CMD+ALT for Mac). In the context of an Bestellungen input form, this results in the following message:

(Text marking added subsequently)

The first highlighted line defines the view name of a detail view (detailsWindow), i.e. addresses a data input form for Bestellungen.

►IMPORTANT◄ To open a view, do not use the shorthand notation from the line above, in which the associated namespace prefix appears instead of the full class name. The context entries with the wildcard symbol * are also not suitable for addressing the view.

The second highlighted line defines the menu node name (order/orderDetails) for the same view, which corresponds to the menu path in the main menu ('Orders/order details').

►NOTE◄ The menu node name does not appear here if a view was not opened via the main menu bar, but e.g. via Open view (Form designer) or by clicking on a function in the ribbon ('New' or 'Edit') in an overview. In this case, there is also no access to help topics (see Online help) that are linked to the menu node name.

While in the context of an Open view (Action) event action, the 'form data' to be assigned for the view to be opened can be provided directly via a value configuration, in the context of the Open view (Form designer) action, one of the following alternatives for data assignment applies depending on the method for selecting the view to be opened (see above):

• With a static definition of the view selection via the View or menu node name parameter, the data assignment is based on the input value ($input) for the action, which is evaluated taking into account the optional Data field parameter. If this defines a data field path that can be evaluated for the input value ($input), this is taken into account for the data assignment. If no Data field is specified, this affects the complete input value ($input). This schema can be regarded as a default use case.
  
  

• The dynamic definition of the view selection expects the name of the view to be opened as the input value ($input) for the action. The data assignment is then exceptionally based on the Data field parameter, which must then specify a data field path that can be evaluated within the complete form data so that a data assignment can take place at all. If no Data field is specified, the data assignment does not take the complete form data into account, but no data assignment takes place.

The effect of a data assignment depends on several factors:

• Which view type should be opened?
  
  

  • A data input form (detailsWindow) maps the detailed data of an individual entity to a form that can be used exclusively for the entity type.

  • An overview (listSearchWindow) enables access to data of multiple entities of the same entity type by mapping the result of a Tuple search to a Data grid.

  • A combined view (listDetailsWindow) combines a data input form and overview (with data grid) for the same entity type in the same view.

  • Portals and Dashboard are not bound to a specific entity type. Unbound views are typically opened via Open portal (or similar).
    
    

  • If the data assignment provides an entity of the entity type to which the view to be opened (data input form, overview, combined view) is linked, this data is processed as follows, depending on the type of view to be opened:
    
    

    • A data input form (detailsWindow) is opened if necessary (see Only one instance) and loads the assigned data into the form.
      
      

    • An overview (listSearchWindow) is opened if necessary (see Only one instance) and the input form applicable for the context also appears as an independent view with the assigned data as form data. The result is similar to the state that a user achieves by opening the data input form from the overview (e.g. via 'New', 'Edit' or by double-clicking). However, an existing entity to which the data assignment relates does not appear selected in the overview if it is displayed there at all due to defined restrictions, filters and paging.
      
      ►IMPORTANT◄ If volatile data for an existing entity is loaded directly into a data input form, it can only be saved successfully – taking into account any changes made in the form – if no newer change status is registered for the entity on the server side than the one from the data assignment. In the event of a conflict, an error occurs when 'saving' and the outdated status with the unsaved changes from the form can only be discarded.
      
      ►NOTE◄ Open view (Action) parameters that control the display behaviour only affect the overview in this constellation and not the data input form opened as a 'secondary' view. In the default view arrangement with only one view slot, the data input form covers the overview. In addition, there is no provision for waiting for a data return from the indirectly opened data input form or for closing this view without returning a value.
      
      

    • A combined view ( listDetailsWindow ) is opened if necessary (see Only one instance) and loads the assigned data into the detail area, i.e. the embedded data input form. If the data assignment relates to an existing entity that can appear in the overview due to any defined restriction (see Custom overviews ), this entity is also selected if it does not appear visible due to paging or applicable filters.
      
      

• What data type does the data assignment provide?
  
  

  • If the data assignment provides the data object of a Search (Search object) or a 'Search restriction' (ISearchRestriction, see Restrictions), this is processed as follows depending on the type of view to be opened:
    
    

    • • A data input form (detailsWindow) may be opened, but appears empty because no restriction can be assigned to a data input form.
        
        

      • An overview (listSearchWindow) or a combined view (listDetailsWindow) is opened if necessary (see Only one instance), whereby the assigned Search or 'Search restriction' is used as a restriction for the list. The view then only lists entities that fulfill the search criteria from the assignment. This 'filter' assigned when opening the view cannot be removed by executing the 'List/Reset' command via the ribbon. If a custom overview (see Eigene Übersichten ) is opened whose definition already provides for a 'Restriction', two cases must be distinguished:
        
        

      • A Sub search is created from an assigned Search, which acts as a restriction for the open overview. The 'Restriction' defined in the custom overview is combined with this Sub-Suche using an AND link (see Such-Verknüpfung).

• • • • An assigned 'Search restriction' is combined directly with the 'Restriction' of the Custom overview using an AND junction.

        ---

        ►IMPORTANT◄ In the context of a Search, Joins can be used to perform the search directly (as an INNER JOIN) or via conditions that refer to Joins via Projections, as these can be transferred to the generated Sub search restriction. If a 'Search restriction' is provided instead, the use of Joins is potentially tricky if they are not mapped via a Chained projection. If the 'Search restriction' uses projections that refer to a 'Join alias', the restriction can only function without errors at runtime if the data grid definition dynamically assigned when opening the view via Association criteria always contains a 'matching' join with this 'Join alias'. If the join does not exist, a database error message appears when the view is opened and the overview is opened without data.
        

The description for the following cases is based on the assumption that the Force load option is unchecked (default).

• • If the data assignment contains another complex data object (neither a 'matching' entity nor a search or search restriction), an attempt is made to obtain a reference to the ID of an entity of the type to which the open view is linked:
    
    

    • If a data field name is specified in the Data field parameter, its return value is processed as described in the next section.

    • If the Data field parameter is not specified, the return value for the id property is processed as described in the next section.
      
      

  • If the data assignment provides a simple value directly or, as described in the previous paragraph, such a value can be obtained from a complex data object, this is interpreted as a reference to the ID of an entity of the type:
    
    

    • If it is not already a Long value, an attempt is made to convert it.
      
      

    • If the view to be opened is linked to an entity type, the system searches for an entity with the specified or determined 'ID' (id). The following case distinction then applies depending on the type of view:
      
      

      • An input form (detailsWindow) is opened if necessary (see Only one instance) and loads the data of the referenced entity into the form.
        
        

      • An overview (listSearchWindow) is opened (see Only one instance) and the input form applicable for the context also appears as a separate view with the data of the referenced entity as form data. The result corresponds to the state that a user reaches by opening the input form from the overview (e.g. via 'New', 'Edit' or by double-clicking). However, the referenced entity to which the data assignment relates does not appear selected in the overview, due to defined restrictions, filters and paging.
        
        ►NOTE◄ In this configuration, Open view (Action) parameters that control the display behaviour only affect the overview and not the data input form opened as a 'secondary' view. In the default view arrangement with only one view slot, the data input form covers the overview. In addition, waiting for a data return from the indirectly opened input form or closing this view without returning a value is not provided for .
        
        

      • A combined view ( listDetailsWindow ) is opened if necessary (see Only one instance) and loads the data of the referenced entity into the detail area, i.e. the embedded data input form. If the referenced entity can appear in the overview due to any defined restriction (see Custom overviews ), this entity is also selected if it does not appear visible due to paging or applicable filters.

If the Force load option is checked, both complex data objects and simple values are assigned directly to the open view, provided it is not a Search or 'Search restriction' (see above).

When the Force load option is checked, a client object (as an example of a complex data object) can be assigned to a portal.

If Force load is not checked, an attempt is otherwise made in this constellation to read the designated Data field (or the default id property) from the complex data object. If this access returns a return value of the Long type or can be converted into a Long value, this value is assigned to the id field in a specially created client object that is transferred to the view (here: portal).

►IMPORTANT◄ The Open view (Action) event action can be used to pause event handling in the call context when a view is opened until the open view is closed or a maximum 'waiting time' expires. The Open view (Form designer) action does not support this procedure. The execution of subsequent actions within the calling behaviour cannot be stopped. Instead, a behaviour can be specified that is executed when the open view is closed. A maximum 'waiting time is not provided.

The optional Execute behaviour after closed parameter specifies the behaviour that is to be executed when the open view is closed. No behaviour is selected by default.

A data return from the open view can only trigger the Request close action, which can only be accessed in the context of a behaviour in a form. Data can therefore only be returned from a view that is a form ( input form, portal, dashboard) or contains a form (combined view). No return value can be transferred from a simple overview without a detail area. Nevertheless, a behaviour can be selected that is executed after the overview is closed.

By default, the dropdown for the Execute behaviour after closed parameter only lists the behaviour names that are defined for the form element with the calling behaviour.

To be able to select and execute a behaviour for another form element within the same form, the element in question must first be linked as a Target element for the Open view (Form designer) action. By default is is set as No target element linked. The target element link can be found – as usual – in the first place under the properties of the action. The editing mode for the link is activated with a mouse click.

↓

►NOTE◄ The Force load option does not affect the 'Display behaviour of the view' but the 'Data assignment for the view to be opened' (see above).

If the Modal option is unchecked (default), the view should be opened as an independent view. The Only one instance option then determines whether the view is also opened if (at least) one instance of the view is already open non-modally – i.e. as an independent view.

If the Modal option is checked, the view is displayed within the current view when it is opened. The Only one instance option is then ignored. Additional options also appear in the configuration:

• The Full size option determines whether a modally opened view should fill the current view as a 'full screen' ('full coverage') or appear as a dialog box centered within the current view.
  
  

  • IIf this option is unchecked (default), additional parameters are displayed that affect the dimensions of the dialog window (Width, Height, Min. width and Min. height). These can optionally be assigned integer values (unit: pixels).
    
    

  • The selection field for Resizable also only applies to the display as a dialog box (i.e.: Full screen unchecked). The selected option controls whether the height and/or width of the dialog can be changed interactively at runtime or not.

• The Closable option is checked by default. It can be unchecked to prevent the title bar of the modal window from displaying the X symbol to close a modally displayed view. This is recommended if a data return from the view (see above) is expected. Otherwise, clicking on the X symbol would close the modal view without executing the behaviour with the Request close action, which is the only way to provide a return object.
  
  

  • The Show "back button" option is only relevant and visible as long as the Closable option is checked (default). It can then be checked differently from the default so that a Back ribbon button appears in the open view (by default on the far left in the main Common category). Clicking on Back closes the modally opened view, just like clicking on the X symbol at the top right of the view title. In both cases, 'No value' ($null) is the return value.

Initially, only three options are visible.

When 'Modal' is checked, further parameters appear.

With 'Full size', some parameters are removed again.

Without 'Closable' the 'Back button' is omitted.