docs: reword prose that still described the one-way/two-way split

Follow-up to the _bind_edit sweep: update the sentences that explained binding
in terms of _bind (one-way) vs _bind_edit (two-way), and drop the last /XX/
model-path references (the prefix no longer exists). Covers tables, trees,
formatter, full_example, dx, snippets, odata, xml_templating, draft_handling,
common_failures and agent.md.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Author: claude

docs/advanced/agent.md

@@ -132,7 +132,7 @@ CLASS zcl_app_xxx DEFINITION PUBLIC.
 
   PUBLIC SECTION.
     INTERFACES z2ui5_if_app.
-    " bound data (public DATA attributes used by _bind / _bind_edit)
+    " bound data (public DATA attributes used by _bind)
 
   PROTECTED SECTION.
     DATA client TYPE REF TO z2ui5_if_client.
@@ -239,7 +239,7 @@ When an AI needs deeper information than this page provides:
 | Architecture, request roundtrip | [Concept](/technical/concept), [How It All Works](/technical/how_it_all_works) |
 | Lifecycle and `IF` / `ELSEIF` dispatcher pattern | [Cookbook → Life Cycle](/cookbook/event_navigation/life_cycle) |
 | Building views, control choice | [Cookbook → View Definition](/cookbook/view/definition) |
-| Data binding (`_bind`, `_bind_edit`) | [Cookbook → Binding](/cookbook/model/binding) |
+| Data binding (`_bind`) | [Cookbook → Binding](/cookbook/model/binding) |
 | Tables and trees | [Cookbook → Tables](/cookbook/model/tables), [Trees](/cookbook/model/trees) |
 | Events, actions, exceptions | [Cookbook → Event, Navigation](/cookbook/event_navigation/life_cycle) |
 | Popups and popovers | [Cookbook → Popup, Popover](/cookbook/popup_popover/popup) |

docs/cookbook/eml_cds_sql/draft_handling.md

@@ -222,7 +222,7 @@ ENDCLASS.
 That's a complete, working draft app. The three numbered comments map one-to-one onto the lifecycle diagram: **open → edit → activate**.
 
 ::: warning Why two steps to save?
-Notice that *Save* does two things: `UPDATE FIELDS` (copy the user's typed values into the draft) **then** `Activate` (promote the draft to active). The fields are two-way bound with `_bind_edit`, so on each roundtrip the user's input lives in your ABAP variables — but it is **not** in the draft yet until you push it back with `UPDATE FIELDS`. Forgetting this step is the most common beginner mistake: the activate succeeds but saves the *old* values.
+Notice that *Save* does two things: `UPDATE FIELDS` (copy the user's typed values into the draft) **then** `Activate` (promote the draft to active). The fields are two-way bound with `_bind`, so on each roundtrip the user's input lives in your ABAP variables — but it is **not** in the draft yet until you push it back with `UPDATE FIELDS`. Forgetting this step is the most common beginner mistake: the activate succeeds but saves the *old* values.
 :::
 
 ## The Full App — A Real-World Edit Screen

docs/cookbook/expert_more/odata.md

@@ -3,7 +3,7 @@ outline: [2, 4]
 ---
 # OData
 
-By default, you bind public attributes of your class to UI5 properties with `_bind` and `_bind_edit`. For cases where you need access to large datasets, you can also use existing OData services. OData offers features like pagination and growing that improve performance with large amounts of data.
+By default, you bind public attributes of your class to UI5 properties with `_bind`. For cases where you need access to large datasets, you can also use existing OData services. OData offers features like pagination and growing that improve performance with large amounts of data.
 
 #### Define Additional Model
 As an example, we use the test OData service `/sap/opu/odata/DMO/UI_FLIGHT_R_V2/`, available on most ABAP systems. Make sure the service is publicly reachable. The method below defines the model and exposes it under the name `FLIGHT`:

docs/cookbook/expert_more/snippets.md

@@ -41,7 +41,7 @@ ENDCLASS.
 
 ## Selection Screen
 
-A classic input form: a few fields bound with `_bind_edit`, a button that triggers backend logic, results shown after submission.
+A classic input form: a few fields bound with `_bind`, a button that triggers backend logic, results shown after submission.
 
 ```abap
 CLASS z2ui5_cl_app_selection DEFINITION PUBLIC.

docs/cookbook/model/formatter.md

@@ -13,7 +13,7 @@ UI5 formatter types use a special JSON-based binding syntax with these key eleme
 
 Note on ABAP syntax: inside string templates (`|...|`), escape the curly braces as `\{` and `\}`, because `{ }` normally denotes an embedded ABAP expression.
 
-The `path = abap_true` parameter on `_bind` / `_bind_edit` returns only the raw model path rather than the full binding expression, so you can embed it inside the `parts` array or a single-path `path:` entry. For `_bind_edit` the path is e.g. `/XX/AMOUNT`; read-only `_bind` paths have no `/XX/` segment (`/AMOUNT`).
+The `path = abap_true` parameter on `_bind` returns only the raw model path rather than the full binding expression, so you can embed it inside the `parts` array or a single-path `path:` entry. The path is e.g. `/AMOUNT`.
 
 For example, this ABAP code:
 ```abap
@@ -93,7 +93,7 @@ ABAP `abap_bool` is `"X"` or `""`. UI5's `CheckBox` expects `true` / `false`. Tw
 ```abap
 )->checkbox( selected = `{= $` && client->_bind( mv_flag ) && ` === 'X' }` )
 ```
-This resolves to `{= ${/MV_FLAG} === 'X' }` — read-only `_bind` paths have no `/XX/` prefix (that segment marks two-way `_bind_edit` bindings). Note that expression bindings cannot write back — checking the box will not flip the ABAP attribute.
+This resolves to `{= ${/MV_FLAG} === 'X' }`. Note that expression bindings cannot write back — checking the box will not flip the ABAP attribute.
 
 **ABAP-side conversion** — keep a parallel `string`-typed attribute (`'true'` / `'false'`) for two-way binding, and translate before/after each event:
 ```abap

docs/cookbook/model/tables.md

@@ -52,7 +52,7 @@ ENDCLASS.
 ```
 
 ### Editable
-To make a table editable, switch the binding to `_bind_edit`:
+To make a table editable, use editable cell controls (e.g. `input`) — the binding is the same `_bind`:
 ```abap
   METHOD z2ui5_if_app~main.
 

docs/cookbook/model/trees.md

@@ -75,4 +75,4 @@ ENDCLASS.
 
 The child table field (`nodes` in the example above) is the key: UI5 follows that field name to locate sub-items at each level. The name must match across all levels but can be anything you choose.
 
-Note that the example binds with `_bind_edit` so that the user's selection (`IS_SELECTED`) is synced back to ABAP. For a purely read-only tree, `_bind` is enough.
+Note that the example binds `IS_SELECTED` to an editable control so the user's selection is synced back to ABAP. A display-only tree needs no editable cells.

docs/cookbook/troubleshooting/common_failures.md

@@ -7,14 +7,14 @@ Not every problem raises an ABAP exception. Many failures surface only in the br
 
 ## Binding-Path Mismatch
 
-When a `_bind` / `_bind_edit` path does not resolve against the JSON model on the frontend — typically because the public attribute was renamed, the data was never sent, or the path is mistyped — UI5 does **not** raise an ABAP exception. The control simply renders empty or with a default value.
+When a `_bind` path does not resolve against the JSON model on the frontend — typically because the public attribute was renamed, the data was never sent, or the path is mistyped — UI5 does **not** raise an ABAP exception. The control simply renders empty or with a default value.
 
 Where to look:
 - **Browser console.** UI5 logs a warning like `Binding "/path/to/field" was not found in model` from `sap.ui.model.json.JSONModel`. Open the browser DevTools console and filter by `sap.ui.model`.
 - **Network tab.** Inspect the abap2UI5 response payload — the JSON model is included verbatim. If the field is absent or named differently than your binding path, you have your answer.
 - **ABAP side.** Nothing. The backend never learns the binding failed. Asserting "no console warnings" is the only way to catch this in tests.
 
-Two-way binding (`_bind_edit`) silently drops the write-back when the path is invalid — your ABAP attribute keeps its old value after the next event. Cross-check the attribute value in the debugger if data is mysteriously not updating.
+Two-way binding silently drops the write-back when the path is invalid — your ABAP attribute keeps its old value after the next event. Cross-check the attribute value in the debugger if data is mysteriously not updating.
 
 ## Bound Attribute Not Public
 

docs/cookbook/view/xml_templating.md

@@ -136,7 +136,7 @@ Plain ABAP control flow covers most cases and is easier to debug. Reach for `tem
 
 #### Tips
 
-- Always bind the data that drives a template (`client->_bind` / `client->_bind_edit`) **before** the builder call that references it. The binding registers the path that `{template>/...}` resolves against.
+- Always bind the data that drives a template (`client->_bind`) **before** the builder call that references it. The binding registers the path that `{template>/...}` resolves against.
 - Inside `template:repeat`, prefer `{var>FIELD}` over deeper paths — it keeps the body readable and lets you nest repeats with distinct `var` names (`L0`, `L1`, ...) without collisions.
 - Use expression binding (`{= ... }`) when the value you need is a binding string itself. Templating-time expressions can read `${var>...}` and concatenate strings, which is how dynamic cell bindings are assembled.
 - If a templated control does not update after a data change, you forgot to rebuild — call `view_display` or `nest_view_display` again.

docs/get_started/full_example.md

@@ -79,7 +79,7 @@ The `main` method is a pure dispatcher — the same pattern as in [Hello World](
 
 Two things are new compared to Hello World: `shell( )` wraps the page in the standard UI5 app frame, and the `navbuttonpress` / `shownavbutton` parameters add a back button when the app was called from another app (details under [Navigation](/cookbook/event_navigation/navigation)). Further down, `get_parent( )` moves one level back up in the builder tree, so the next `column( )` becomes a sibling instead of a child — see [View → Definition](/cookbook/view/definition).
 
-The two date pickers and the customer input use `_bind_edit`, so whatever the user types travels back to the ABAP attributes automatically. The table uses read-only `_bind` since the rows are only displayed:
+The two date pickers and the customer input are bound with `_bind`, so whatever the user types travels back to the ABAP attributes automatically. The table is bound with `_bind` too; since its cells are display-only, nothing syncs back:
 
 ```abap
   METHOD view_display.
@@ -219,7 +219,7 @@ A popup is built exactly like the main view — same fluent builder, just create
   ENDMETHOD.
 ```
 
-The date picker in the dialog binds to `s_edit-delivery_date` with `_bind_edit` — when the user picks a new date, the attribute is already updated by the time the next event reaches your ABAP code.
+The date picker in the dialog binds to `s_edit-delivery_date` with `_bind` — when the user picks a new date, the attribute is already updated by the time the next event reaches your ABAP code.
 
 ### Step 5 — Posting the Change