docs: sync frontend/binding docs with the unified root model and view parameter

- nested_views: the per-view model separation is gone (all _bind data goes to
  one root model) and _bind's view parameter is now an inert no-op; rewrite the
  routing section to choose the target view via the matching
  ..._view_model_update() call and drop the no-op view= from the examples
- frontend: refresh the stale cs_event listing and document the whitelisted
  control_by_id/control_global/binding_call calls plus the new view importing
  parameter on _event_client
- follow_up_action: document the whitelisted control calls and the view
  parameter
- xml_templating: drop a leftover duplicate _bind reference from the
  _bind_edit sweep

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NjYGeMm8yvpJhavp6hdGyN

Author: claude

docs/cookbook/event_navigation/frontend.md

@@ -14,28 +14,39 @@ The following frontend events are available:
 ```abap
   CONSTANTS:
     BEGIN OF cs_event,
+
+      "Framework
       popup_close               TYPE string VALUE `POPUP_CLOSE`,
-      open_new_tab              TYPE string VALUE `OPEN_NEW_TAB`,
       popover_close             TYPE string VALUE `POPOVER_CLOSE`,
-      location_reload           TYPE string VALUE `LOCATION_RELOAD`,
-      nav_container_to          TYPE string VALUE `NAV_CONTAINER_TO`,
-      nest_nav_container_to     TYPE string VALUE `NEST_NAV_CONTAINER_TO`,
-      nest2_nav_container_to    TYPE string VALUE `NEST2_NAV_CONTAINER_TO`,
+      set_size_limit            TYPE string VALUE `SET_SIZE_LIMIT`,
+      set_odata_model           TYPE string VALUE `SET_ODATA_MODEL`,
       cross_app_nav_to_ext      TYPE string VALUE `CROSS_APP_NAV_TO_EXT`,
       cross_app_nav_to_prev_app TYPE string VALUE `CROSS_APP_NAV_TO_PREV_APP`,
-      popup_nav_container_to    TYPE string VALUE `POPUP_NAV_CONTAINER_TO`,
-      download_b64_file         TYPE string VALUE `DOWNLOAD_B64_FILE`,
-      set_size_limit            TYPE string VALUE `SET_SIZE_LIMIT`,
+
+      "Actions
+      clipboard_copy            TYPE string VALUE `CLIPBOARD_COPY`,
+      clipboard_app_state       TYPE string VALUE `CLIPBOARD_APP_STATE`,
       set_title                 TYPE string VALUE `SET_TITLE`,
       set_title_launchpad       TYPE string VALUE `SET_TITLE_LAUNCHPAD`,
       set_focus                 TYPE string VALUE `SET_FOCUS`,
       scroll_to                 TYPE string VALUE `SCROLL_TO`,
       scroll_into_view          TYPE string VALUE `SCROLL_INTO_VIEW`,
       start_timer               TYPE string VALUE `START_TIMER`,
       keyboard_set_mode         TYPE string VALUE `KEYBOARD_SET_MODE`,
-      clipboard_copy            TYPE string VALUE `CLIPBOARD_COPY`,
-      clipboard_app_state       TYPE string VALUE `CLIPBOARD_APP_STATE`,
+      open_new_tab              TYPE string VALUE `OPEN_NEW_TAB`,
+      location_reload           TYPE string VALUE `LOCATION_RELOAD`,
+      system_logout             TYPE string VALUE `SYSTEM_LOGOUT`,
+      download_b64_file         TYPE string VALUE `DOWNLOAD_B64_FILE`,
+      urlhelper                 TYPE string VALUE `URLHELPER`,
       history_back              TYPE string VALUE `HISTORY_BACK`,
+      store_data                TYPE string VALUE `STORE_DATA`,
+      play_audio                TYPE string VALUE `PLAY_AUDIO`,
+
+      "Control calls (whitelisted, positional t_arg)
+      control_by_id             TYPE string VALUE `CONTROL_BY_ID`,
+      control_global            TYPE string VALUE `CONTROL_GLOBAL`,
+      binding_call              TYPE string VALUE `BINDING_CALL`,
+
     END OF cs_event.
 ```
 For example, to open a new tab directly from a button press (no backend involved):
@@ -52,3 +63,43 @@ METHOD z2ui5_if_app~main.
 
 ENDMETHOD.
 ```
+
+## Calling control methods on the frontend
+
+The last three constants — `control_by_id`, `control_global` and `binding_call` — are frontend events too, but instead of a fixed built-in action they invoke a *whitelisted* method on a control, a global object or a binding. Their arguments are **positional**: an empty argument between two filled ones keeps its slot as `` `` ``.
+
+| Event            | `t_arg` (positional)                                                                 |
+| ---------------- | ------------------------------------------------------------------------------------ |
+| `control_by_id`  | `id`, `method`, `params…` — call a whitelisted method on a control resolved by id     |
+| `control_global` | `object`, `method`, `params…` — `MESSAGE_TOAST`, `MESSAGE_BOX`, `BUSY_INDICATOR`, `THEMING` |
+| `binding_call`   | `path`, `method`, `params…` — e.g. `filter` (operator, value1, value2) or `sort` (path, descending, group) |
+
+```abap
+" toggle a MessagePopover open, anchored to the pressing button, no roundtrip
+press = client->_event_client(
+    val   = client->cs_event-control_by_id
+    t_arg = VALUE #( ( `msgPopover` ) ( `toggleBy` ) ( `${$source>/id}` ) ) )
+```
+
+The same events also work from the backend with `client->follow_up_action( )` using the identical `t_arg`.
+
+### The `view` parameter
+
+For `control_by_id`, the control is looked up by id. Both `_event_client( )` and `follow_up_action( )` take a separate `view` parameter (default `cs_view-main`) that scopes this lookup:
+
+- omit it (or pass `cs_view-main`) — the id is resolved across all open views;
+- pass `cs_view-popup` / `cs_view-popover` / `cs_view-nested` / … — the lookup is scoped to a control hosted in that view (e.g. a control living inside a popup).
+
+```abap
+" call a method on a control that lives inside the popup view
+press = client->_event_client(
+    val   = client->cs_event-control_by_id
+    view  = client->cs_view-popup
+    t_arg = VALUE #( ( `NavCon` ) ( `to` ) ( `${$parameters>/selectedKey}` ) ) )
+```
+
+::: tip Migrated from a positional view slot
+The view used to be the second entry of `t_arg` (`id`, `view`, `method`, …). It is now the dedicated `view` importing parameter, so main-view calls simply omit it. Older examples that still pass `` `MAIN` `` as the second `t_arg` element continue to work.
+:::
+
+`control_global` and `binding_call` are not resolved by id and ignore `view`.

docs/cookbook/expert_more/follow_up_action.md

@@ -53,4 +53,30 @@ client->follow_up_action( `myFunction()` ).
 plain event name (only `A-Z`, `a-z`, `0-9`, `_`) becomes a frontend event call,
 anything containing JavaScript syntax runs verbatim.
 
+## Calling a control method
+
+The whitelisted control calls — `cs_event-control_by_id`, `control_global` and
+`binding_call` — are frontend events too, so `follow_up_action( )` can invoke a
+method on a control once the backend response arrives. Their `t_arg` is
+positional (see [Frontend → Calling control methods](/cookbook/event_navigation/frontend#calling-control-methods-on-the-frontend)):
+
+```abap
+" after backend processing, advance a wizard step
+client->follow_up_action(
+    val   = client->cs_event-control_by_id
+    t_arg = VALUE #( ( `wiz` ) ( `setNextStep` ) ( `STEP2` ) ) ).
+```
+
+For `control_by_id`, the control is resolved by id. A separate `view` parameter
+(default `cs_view-main`, which resolves the id across all open views) scopes the
+lookup to a single view — pass `cs_view-popup` / `cs_view-popover` / … for a
+control hosted in a popup or popover:
+
+```abap
+client->follow_up_action(
+    val   = client->cs_event-control_by_id
+    view  = client->cs_view-popup
+    t_arg = VALUE #( ( `NavCon` ) ( `to` ) ( `detail` ) ) ).
+```
+
 See sample `Z2UI5_CL_DEMO_APP_180` for a complete example.

docs/cookbook/view/nested_views.md

@@ -103,8 +103,7 @@ DATA(lr_master) = page->flexible_column_layout(
                        id     = `test`                            " anchor
                      )->begin_column_pages( ).
 
-lr_master->list( items = client->_bind( val  = t_tab
-                                             view = client->cs_view-main )
+lr_master->list( items = client->_bind( t_tab )
                  selectionchange = client->_event( `SELCHANGE` )
   )->standard_list_item( title    = `{TITLE}`
                          selected = `{SELECTED}` ).
@@ -119,8 +118,7 @@ METHOD view_display_detail.
   DATA(lo_view_nested) = z2ui5_cl_xml_view=>factory( ).
   DATA(page) = lo_view_nested->page( `Nested View` ).
 
-  page->ui_table( rows = client->_bind( val  = t_tab2
-                                             view = client->cs_view-nested ) ).
+  page->ui_table( rows = client->_bind( t_tab2 ) ).
   " ...columns, toolbar, row actions...
 
   client->nest_view_display(
@@ -139,26 +137,24 @@ End-to-end samples:
 - `Z2UI5_CL_DEMO_APP_097` — list master, `sap.ui.table.Table` in the detail with sort/filter/row actions.
 - `Z2UI5_CL_DEMO_APP_085` — full master-detail with an `ObjectPageLayout` as the nested detail, including search, sort, and the FCL fullscreen toggle.
 
-#### Routing Bindings to the Right View
+#### Refreshing the Right View
 
-Each view (main, nested) has its own client-side model. When you build a binding with `client->_bind( ... )` you can declare which view's model the binding belongs to via the `view` parameter:
-
-```abap
-" In the main view
-items = client->_bind( val = t_tab  view = client->cs_view-main )
-
-" In the nested view
-rows  = client->_bind( val = t_tab2 view = client->cs_view-nested )
-```
-
-The constants `client->cs_view-main` and `client->cs_view-nested` are abap2UI5's view identifiers. Declaring them lets `nest_view_model_update( )` know which model to refresh:
+All bound data lives in a **single client-side model**, regardless of which view a binding was built in — `client->_bind( ... )` always writes to that one root model. What differs is *which rendered view you refresh* after the ABAP data changes: call the update method that matches the view.
 
 ```abap
 DELETE t_tab2 WHERE title = ls_arg-title.
-client->nest_view_model_update( ).   " only the nested view's data is pushed
+client->nest_view_model_update( ).   " push the new data into the nested view
 ```
 
-If you omit `view`, the binding defaults to the main view, which still works for many cases but is less explicit. Get into the habit of passing the right `cs_view-...` value whenever a fragment is built — it makes the data flow obvious to anyone reading the code.
+| Rendered view | Refresh call                          |
+| ------------- | ------------------------------------- |
+| main          | `client->view_model_update( )`        |
+| nested        | `client->nest_view_model_update( )`   |
+| nested (2nd)  | `client->nest2_view_model_update( )`  |
+
+::: tip `_bind`'s `view` parameter is obsolete
+Earlier releases kept a separate model per view and asked you to tag each binding with `view = client->cs_view-...` so the framework knew which model to refresh. That separation is gone — there is now one root model — and the `view` parameter of `_bind` / `_bind_edit` is an inert no-op kept only for backward compatibility. Omit it, and pick the target view through the matching `..._view_model_update( )` call instead.
+:::
 
 #### Two Levels of Nesting
 

docs/cookbook/view/xml_templating.md

@@ -19,7 +19,7 @@ This timing has two consequences:
 - **Expansion is build-time.** A `template:repeat` over an internal table produces a fixed number of controls; the expanded XML is what UI5 renders.
 - **Data changes do not re-template.** If the data driving the template changes, the existing expansion stays as is. To pick up the change you must rebuild the view (`view_display`) or the templated fragment (`nest_view_display`) — see [Re-rendering](#re-rendering) below.
 
-abap2UI5 wires up the templating model for you. Every variable you bind with `client->_bind( ... )` or `client->_bind( ... )` is reachable inside templates via the `template>` model prefix:
+abap2UI5 wires up the templating model for you. Every variable you bind with `client->_bind( ... )` is reachable inside templates via the `template>` model prefix:
 
 | ABAP binding                       | Path inside templates       |
 | ---------------------------------- | --------------------------- |