Open view (Action)

The View name can be addressed either by direct text input or by a value trigger.

A view is opened only when:

1. The specified string exactly matches an existing menu node name or view name.

2. There are sufficient authorizations for the role used.

3. If applicable – at least one relevant configuration for the context in question is assigned at runtime (see Association criteria, Company authorizations).

Whether the following sample values for the View name parameter work partly additionally depends on which modules are licensed by Lobster Data Platform / Orchestration:

• documentation ... opens the Orchestration Manual by menu node name

• documents ... opens the overview Documents by menu node name (if module is licensed)or de.lobster.scm.doc::Document|listDetailsWindow ... per view name

• order/orderDetails ... opens an input form for Orders by menu node nameor de.lobster.scm.order.bto::Order|detailsWindow ... same as per view name

• Portal$SELECT_PORT ... opens a portal with the internal name SELECT_PORT by view name

• dashboard$KPI2020 ... opens a dasboard with the internal name KPI2020 by view name

►NOTE◄ By clicking on the gray arrow at the bottom left of the input field for the Portal XML parameter, it is possible to switch from direct input mode to the definition of a value resolver:

If a view cannot be opened, no exception occurs. Event handling is then usually continued immediately, i.e. without waiting for a possibly parameterized Wait time value return (see below).

How to determine the view name or menu node node name:

View name and menu node name of a view that is already opened can be determined by clicking on the ? symbol in the upper right corner of the window title, which results in the following message in the example of an input form for Orders (text marking added later):

The first marked row defines the view name of a detail view (detailsWindow), i.e. addresses an input form for Orders.

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

The second highlighted row defines the menu node name for the same view, which corresponds to the 'Orders/Order Details' menu path in the main menu in the default configuration.

►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 (Action) or by clicking on a function in the ribbon ('New' or 'Edit'). Then there is also no access to help topics (see Online help) that are linked to the menu node name.

Data assignment for the View name

The value configuration for the Form data parameter can be used in different ways to transfer dynamically determined information to the View name, if this is provided for at all.

The decisive factor is the data type returned by the value resolver in combination with the type of view to be opened.

Open a view of the input form type (detailsWindow):

• If a Long value or a compatible simple value (e.g. a text such as '4711') is transferred as Form data, the open input form loads the data of the entity with the ID in question, provided it exists and there is at least read access.

  • If the entity does not exist, the input form appears 'empty' (without data).

  • If there is no read access for the 'requested' entity, an error message appears (notification of the 'Error' type) and the input form is opened 'empty'.

    However, no exception occurs, so that event handling is continued either immediately after the waiting time has expired or when the view is closed.

• If any data object (not an entity of the data type linked to the input form) is transferred as Form data, which has an id property with a value that can be interpreted as long at header level, an instance with this id is searched for among the entities of the type specified by the input form in order to display it. This logic is helpful, for example, if the view to be displayed should show an entity that was determined in the context of the calling event handling via a Tuple search that contains, among other things, a Property projection for the 'ID' (id) property. Each result value from this search is then a client object with an id property. If this client object is assigned as Form data, the complete entity is retrieved automatically when the data input form is opened.

• If a complete entity whose type corresponds to the context of the data input form to be opened is transferred as Form data, then this entity directly provides the form data for the opened data input form. This is also the case if the relevant data object has not yet been saved. The data object for a new entity can also be provided via Create instance, for example. However, in this case the 'New' event (see Common action event) is not triggered.

  ►IMPORTANT◄ A data input form only registers changes as 'unsaved' that are made after the form has been opened. If an Entity passed via Open view (Action) has been newly created and/or modified by previously executed event actions, the form does not recognize that these changes should still be saved. Unless further changes are made interactively or automatically within the form, the usual warning ('Discard changes?') before a 'Cancel' or 'Close' of the view is omitted and the displayed data may be partially or completely lost.

Open a view of the type Overview (listSearchView):

• If a Search (a Search object) is provided as Form data as a data object for a pure overview (listSearchView), then a Sub search is generated from its definition, which acts as a 'restriction' for the opened overview. The opened overview then only lists entities that match the search criteria of the transferred Search. If a custom overview (see Custom overviews) is opened whose definition already provides for a 'restriction', this is combined with the Sub search using an AND operation (see Search junction). This 'filter' assigned when opening cannot be removed by executing the 'List/Reset' command via the ribbon.

• If a data object that describes a 'Search restriction' (ISearchRestriction, see Restrictions) is transferred as Form data, this is either used directly as a 'Restriction' for the open overview or – in the case of a custom overview – is AND-linked with the predefined 'Restriction', if applicable.

►IMPORTANT◄ In the context of one of the Search (first case above), Joins can be used to perform the search directly (as an INNER JOIN) or through conditions that refer to Joins via Projections, as these can be included in 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 that is dynamically assigned via Association criteria when the view is opened 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.

• If the Form data when opening an overview corresponds to one of the contents listed under 'Opening a view of the input form type' (long value, complete entity, etc.), then two cases must be distinguished:

  • If the open view is a combined view (listDetailsWindow) that combines a data grid with a detail area defined as a data input form, the entity transferred or referenced by Form data is selected in the data grid and the associated details appear in the detail area.

  • If the open view is a pure overview (listSearchWindow), a view with the overview is primarily opened. On the other hand, the applicable input form in the context (detailsWindow) is opened in another view to display the data object transferred or referenced by Form data.

    • The data input form in the second open view is treated exactly as if a double-click had been made on the corresponding entity in the data grid of the overview. It is displayed non-modally in a completely independent view, for which the parameterization regarding display behavior (see below) in the Open view (Action) has no relevance. In addition, waiting for a data return from the indirectly opened input form is not provided for

    • If an entity referenced by ID is not 'found' because it does not exist or there is no read access, the input form is opened 'empty'.

Data return from the view (optional)

The optional Name of result variable parameter of the return object can be used to specify the name of a variable that can be used to access return data from the opened view, provided that:

• A Wait time >0 (unit: seconds) is configured.

• And the Request close action is executed in the portal at runtime before this waiting time expires.

If a Wait time (>0 seconds) elapses without Request close being executed, the view is automatically closed and the return data is empty.

If, on the other hand, the Wait time is set to 0 (default), event processing continues immediately after the view is opened and without waiting for the return data.

►NOTE◄ The Wait time parameter can also be used without the Name of result variable to display a specific view for a limited time.

CAUTION If an input form is closed after the Wait time has elapsed, unsaved changes are lost without any further confirmation.

►IMPORTANT◄ The Wait time must be >0 so that the portal is called 'synchronously'. Only then will a Request close action wait for return data in the portal.

If the portal is closed without executing the Request close action with the data to be returned as input value ($input), the return object variable remains empty. (see also the Closeable option below).

View display behavior

If the Modal option is not selected (default), the view should be opened as a separate view. Then the option Unique decides whether the view is opened, even if (at least) one instance of the view is already open non-modally – i.e. as a separate view.

IIf the Modal option is selected, the view is displayed within the current view when it is opened. The option Unique is then ignored. Additional options also appear in the configuration:

• The Fullscreen option decides whether the modally opened view fills the current view as a 'fullscreen' or appears as a dialog box within this view.

• • If 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 icon would close the modal view without executing the behavior 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 selected 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, any defined Wait time ends without a return value.

►NOTE◄ The Back button can be influenced as a ribbon macro by combining the subcategory modal (not included in the dropdown!) with the macro name back. A macro command ('Always deactivated' or 'Always hidden') can then also be used to specifically prevent a modal view from being closed via Back.

CAUTION If the Modal option is checked when opening a view and the Closable option is unchecked, it should be ensured that another method enables the view to be closed:

• If a finite value (>0) is specified in the Wait time parameter, a modally opened view of any type is automatically closed after this wait time has expired.

• Forms (Input forms, Portals and Dashboard) can provide any trigger for a behavior with a Request close action (e.g. Button or Ribbon button (Portal)).

• For Input forms and overviews, a ribbon macro can be used to trigger the 'Common/Close' command (see Available commands) in the context of a macro.

• Combined views can provide both the Request close action (in the detail area) and access to the 'Common/Close' command (see Available commands) via a ribbon macro.

If none of these options are applicable, a modally opened view that is not Closable can only be exited by closing the parent view.

The Open after commit option is unchecked by default so that the View name is executed immediately when Open view (Action) is executed.

• If Open after commit is unchecked, the View name is only marked for opening on successful completion of the current transaction or event processing. The view then only appears if neither an error with rollback occurs nor an Abort event action is executed.

• A 'Data return from the view' (see above) is not supported if the Open after commit option is checked. Therefore, the associated parameters (see above) are only visible and relevant as long as the Open after commit option is unchecked.

►NOTE◄ To open a view with a data return 'after the commit', a Dispatch action event event action should be executed with the corresponding option. In the event handling for the triggered event, Open view (Action) can then be executed without the Open after commit option but with 'Data return' instead.