42 lines
6.7 KiB
Markdown
42 lines
6.7 KiB
Markdown
# Edit Views and bindings
|
|
|
|
Both hosts use the same Kit hierarchy, canvas, inspector and Bindings panels. **Source**, **Design** and **Split** share one authoritative host document. Supported actions produce lexical replacements rather than serializing the whole FXML tree. Comments, processing instructions, quote style and unrelated declarations remain intact. Each accepted operation is one host Undo/Redo command; invalid FXML may still be saved for later repair.
|
|
|
|
## Canvas and Component properties
|
|
|
|
Select an object in the hierarchy or canvas, edit supported scalar/layout properties, or drag/resize it. Standard controls remain ordinary Kit objects; application Components use target-rendered placeholders. Explicit width/height and supported attached layout constraints are editable, including nested/anonymous Components and `fx:root` bodies. A corner resize changes both dimensions in one transaction.
|
|
|
|
Unsupported structural proposals are rejected instead of rewriting unknown XML. Use the shared Structure panel for the supported operations below and Source for everything else. Application-specific property editors, arbitrary custom object values and generic FXML language coverage are not implied by successful pixel rendering. In particular, importing an application enum solely for `<Role fx:constant="..."/>` can be misclassified by the host projection. The reference Desk populates its ChoiceBox in Controller initialization instead; ordinary NeitzelLib/FXMLLoader applications can still use enum constants.
|
|
|
|
## Discovery and authoring
|
|
|
|
Build first, declare the Model with `<?neitzel-model ...?>`, then open **Bindings**. Discovery shows Model Attributes and nested paths, selected ViewModel, target types, collection elements and compatible Component/Row types. Direction-aware checks compare what will be read and written; a plausible name is not sufficient compatibility evidence.
|
|
|
|
| Panel | Typical workflow | Reference example |
|
|
| --- | --- | --- |
|
|
| Direct bindings | Choose target control/property, Model path, `view`/`model`/`both`, optional Converter; create, update or remove | `nameField.text` ↔ `name`; age through `AgeConverter` |
|
|
| Computed bindings | Select target control/property and a public zero-argument Controller method; create, update or remove | `greetingLabel.text` from `DeskController.greeting()` |
|
|
| Repeat | Select a Pane, collection Attribute and compatible Component; edit/remove the declaration | `visits` rendered as `VisitForm` instances |
|
|
| Table / Columns | Select Table, collection Attribute and Row; author ordered Columns and inspect Row alignment | `visitTable` with `VisitRow` cells |
|
|
| Structure | Rename identifiers, copy/paste or delete a subtree with associated references | Duplicate a nested layout section without identifier collisions |
|
|
| Problems | Inspect diagnostics, navigate to source and apply an explicitly selected supported fix | Correct an invalid DirectBinding direction |
|
|
| Generate View | Review metadata-based form choices before creating new FXML | New form for Person; see [generation](generation.md) |
|
|
|
|
All three DirectBinding directions initialize the control from the Model. After initialization, `view` updates the View from the Model; `model` updates the Model from the View; `both` requests both directions. ObservableList-valued Attributes use shared list identity: list mutation does not follow these scalar direction/Converter semantics. Runtime and target compatibility remain authoritative, including conversions and generic types. Creating a declaration does not create the named Java class or method.
|
|
|
|
Converters are discovered from compiled classes without constructing them. Explicit capabilities permit direction-aware suggestions; an unannotated Converter can remain valid runtime code but produce an unverified warning. Configure and test its behavior in the application. The [Converter contract](../converter-validation.md) documents the optional capability annotation and validation details.
|
|
|
|
Computed suggestions come from the actual Controller (the Component itself for its fx:root View). Methods must be public, take no arguments and return a compatible value. Use `#method`; there are no Model path, direction, observed-path or Converter fields. Discovery does not execute methods or prove their runtime refresh behavior. The editor does not implement arbitrary expression languages. Repeat discovery requires a supported collection and compatible element Model. Repeat and Table select a direct collection Attribute/property on the current ViewModel, not DirectBinding-style dotted traversal. Table discovery additionally compares ordered Columns with the declared Row's cells. Missing or ambiguous generic/Row information is reported rather than guessed. **Open Row Component** is the explicit action for editing its FXML separately.
|
|
|
|
## Reference-safe structure changes
|
|
|
|
Renaming `fx:id` also updates supported binding targets and ordinary `$id`, simple `${id.property}`, `fx:reference` and `fx:copy` references. Copy assigns fresh descendant identifiers and carries associated bindings; paste validates them in the destination Model/Controller context. Delete removes the selected subtree and bindings targeting its descendants. These actions never refactor Java Controller fields, Model paths or separately stored Component definitions.
|
|
|
|
Paste targets supported standard Pane children (VBox, HBox, Pane, AnchorPane, StackPane, FlowPane, TilePane, GridPane). The clipboard is shared between editors in the same host process, not the OS or separate host processes. Complex expressions, scripts, includes, ambiguous imports, cross-View relative resources, document-root copy/delete and unsupported child properties require Source review. Native Kit reparent/delete/clipboard proposals are not a substitute for these shared actions. See [exact structural limits](../reference-safe-structure.md).
|
|
|
|
## Diagnostics and quick fixes
|
|
|
|
Problems are scoped to open designer documents and current build/draft evidence. Selecting a problem navigates to the affected FXML location. Source underlines follow the same ranges. IntelliJ also exposes Problems entries, native XML annotations and **Alt+Enter** actions. This is not a whole-project background inspection or precise Java-source navigation service.
|
|
|
|
Errors block new previews; warnings remain visible and permit preview. Stale diagnostic actions are withdrawn after edits or build changes. Available fixes are deliberately narrow: explicit DirectBinding direction choices, removing a later duplicate Direct/Computed target, and removal of eligible simple invalid Direct/Computed/Repeat declarations. Tables, unknown/nested payloads, warnings and declarations with `fx:id` do not get speculative deletion fixes. No action is auto-selected. Fixes preserve unrelated source and use normal Undo/Redo; see [supported fixes](../source-highlighting-fixes.md).
|