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 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 name
  or 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.

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 behaviour (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'.

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).

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 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 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.

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 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.

In the example, the myOrder parameter with the value 4351 is appended to the URL for calling the client:

Even before the actual session begins, an input form with details of the order with the ID '4351' appears in a compact, modally opened input form. This could be called up by scanning a barcode, for example.

►NOTE◄ The ID field has been visibly included in the form layout in this example for clarification, which in practice is neither usual nor necessary.

• After selecting a position via the Select Button in the input form (top right), the form is closed. Instead, an order overview (on the right) appears, listing only orders that have at least one item with the same Goods description as the selected item.

►NOTE◄ The selection criterion (matching Goods description) for the orders to be displayed was deliberately chosen superficially in the example to simplify matters. In a practical application, more complex criteria (e.g. a combination of creation period, work status, article number, EAN, etc.) would be typical.

The screenshot on the right shows an overview of the event handling to be created. Then configuration details are described section by section.

• The Client logged in event is selected under Triggering events (see Login (Events)), in the context of which all URL parameters used are available as string variables.

• The Validating rule is an Entity property rule that checks whether the myOrder variable is 'not-empty". This is the case if a value has been specified for the URL myOrder parameter.

►NOTE◄ It is neither explicitly checked here whether the passed string can be interpreted as a Long value, nor whether there is read access to an order with a matching ID within the logged-in session. Corresponding checks could be added within the rule or in an If then else event action in order to prevent an empty input form for purchase Orders from appearing.

• In the Action on passed rule area, an Open view (Action) event action is executed first, which opens the input form with the details of the order (detailsWindow) identified by URL parameter (see below for details).
  
  

• The following Execute with event action is only executed when the open input form is closed. If this is done by clicking the Select Button for a concrete item, the corresponding entity of the 'Order line item' type will be saved in a selectedLineItem variable. This is defined in the Object Resolver of the Execute with event action as the reference object for the action block.
  
  

• The action block here contains a second instance of an Open View (action), which opens an order overview (listSearchWindow) with the orders 'matching' the selected item.

►NOTE◄ A check to see whether an item has been selected in the input form is omitted here. In practice, an If then else event action would be recommended, which only executes the Execute with event action if the selectedLineItem variabl e is 'not empty'.

To open the input form with the details of the order specified by URL parameter, the first Open view (Action) event action is parameterized as shown on the right:

• The corresponding View name (de.lobster.scm.order.bto.Order|detailsWindow) is entered as the 'Open view'.
  
  

• A Variable resolver is used in the Form data parameter to pass the value of the myOrder URL parameter. If the text value contained can be interpreted as a long value (integer), the open entry mask attempts to display the details of the order with the specified ID.
  
  

• As a Name of result variable, the name selectedLineItem is chosen, to which the following Execute with event action refers to. This Variable contains data only if it is assigned in a behaviour in the input form by a Request close action. This is done in the example by the Select Button, which assigns the column layout data for a single item.

• The Wait time must be set >0 (seconds), otherwise no return value will be waited for. If the user does not make a decision within the 900 seconds parameterized here, the input form is closed automatically without any query regarding 'Discard changes' and without writing a return value to the selectedLineItem variable.

• The other options can be set, for example, as shown. The Modal and Fullscreen options in combination with the triggering event 'Client logged in' causes the entire browser window to be used for the display as an exception, since neither the main menu nor the view slots are displayed directly after the login.

The following Execute with event action is configured as shown on the right to tailor the search criterion for the order overview to be opened based on the order item ('Order > Item') passed as a return value in the selectedLineItem variable.

• The Object resolver accesses the variable selectedLineItem via a Variable resolver (collapsed in the image).

• In the action block, the second Open View (action) instance is executed directly, which addresses the default context for the order overview(de.lobster.scm.order.bto.Order|listSearchWindow) as the View name.

• As Form data, a Search object (see Search) is generated by a concatenation of value resolvers, which contains the condition for the orders listed:
  

  • First, a static XML is stored in a text value resolver (see Static values), which contains the character string @1:s@ as a placeholder for the value of the 'Goods description' intended as a criterion.

• • The placeholder (@1:s@) will be replaced by the text value of the 'Goods description' from the text attribute (GOODS_DESCRIPTION) of the selected order item by Replace text at runtime.

• • A search object is then generated from the XML string modified at runtime by a Server xml to object, which causes a 'restriction' for the order overview to be opened as the value for the Form data parameter.

►NOTE◄ The static XML string for the search object was created for this example using the Search builder in the following steps:

1. Configure and test a query of the 'Search' type for the entity type in question.
   
   

2. Select the XML tab in order to to edit the XML string of the query definition.
   
   

3. Copy all namespace attributes from the core:SearchTask element to the core:Search element.
   
   

4. Copy the prepared core:Search element (see marker in screenshot below) completely to the clipboard and paste it into a value resolver for static text within event handling.
   
   ►NOTE◄ The marking from line 3 onwards already contains the copied xmlns attributes (namespaces) from line 2. It would therefore also be possible to simply delete lines 2 and 24 to obtain the XML definition for the desired search object.

►NOTE◄ Alternatively, a search object or the associated XML string can also be read at runtime from an existing configuration (e.g. External search or Custom overviews) and then adapted, generated via a Lobster_data profile (via Lobster SCM templates) or even created via Create instance within event handling and then 'suitably' built up step by step.