📜 Codex: Documentation Synchronization and Architectural Articulation - #312
📜 Codex: Documentation Synchronization and Architectural Articulation#312tedd wants to merge 1 commit into
Conversation
…ents - Clarify DataContext recursive visual tree inheritance and local override pitfall. - Detail that routed event traversal does not terminate on e.Handled = true. - Modernize README.md code snippets using C# collection initializers. - Append journaling observations to .jules/codex.md. Co-authored-by: tedd <493224+tedd@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
There was a problem hiding this comment.
Pull request overview
Updates project documentation to more precisely describe DataContext inheritance and routed-event handling behavior, and refreshes the README’s foundational layout snippet to use modern C# collection-initializer syntax.
Changes:
- Refactors the README UI layout snippet to initialize
StackPanel.Childrenvia collection initializers. - Expands the README’s “DataContext Inheritance” and “Execution Phases” sections with more explicit architectural explanations.
- Adds a new entry to
.jules/codex.mddocumenting the intent of these documentation synchronizations.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| README.md | Updates the example layout snippet and refines DataContext + routed-event documentation. |
| .jules/codex.md | Records the documentation synchronization rationale and scope. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ### Data Binding | ||
| Tedd.TUI implements a hierarchical data binding infrastructure analogous to WPF, systematically driven by the `DataContext` inherited dependency property. This established framework capability mitigates the need for speculative manual state synchronization. | ||
| - **DataContext Inheritance:** The `DataContext` property is an explicitly defined inherited dependency property. The `DependencyObject` base architecture resolves inherited values by recursively querying `InheritanceParent` (which maps to `Parent` in `UIElement`). Assigning a `DataContext` at the visual root (e.g., `TuiWindow`) makes the data model available to descendant elements that have not set a local `DataContext`. Propagation is implemented in `UIElement.OnPropertyChanged` for inherited dependency properties by enumerating `GetVisualChild` and calling `OnPropertyChanged(dp)` on children that do not have a local value, which in turn updates bindings. | ||
| - **DataContext Inheritance:** The `DataContext` property is an explicitly defined inherited dependency property. The `DependencyObject` base architecture resolves inherited values by recursively querying `InheritanceParent` (which maps to `Parent` in `UIElement`) across the visual tree. Assigning a `DataContext` at the visual root (e.g., `TuiWindow`) makes the data model available to descendant elements that have not set a local `DataContext`. Propagation is implemented in `UIElement.OnPropertyChanged` for inherited dependency properties by enumerating `GetVisualChild` and calling `OnPropertyChanged(dp)` on children that do not have a local value, which in turn updates bindings. Explicitly setting a local `DataContext` value on child controls (e.g., within `OnDataContextChanged` overrides or container setters) incorrectly overrides and breaks this WPF-isomorphic inheritance mechanism until cleared via `ClearValue`. |
| - **Standard Input Events:** Primitive interactions (`KeyDown`, `KeyUp`, `MouseDown`, `MouseUp`, `GotFocus`, `LostFocus`) are registered via `RoutedEvent.Register`. The core supports comprehensive `RoutingStrategy` execution topologies: `Tunnel` (down from root to leaf), `Bubble` (up from leaf to root), and `Direct` (local invocation isolated to the source). | ||
| - **Control State Events:** Interactive toggle controls (`CheckBox`, `RadioButton`) implement `Checked` and `Unchecked` bubbling routed events, dispatching dynamically from their `OnPropertyChanged` overrides when `IsCheckedProperty` mutates, guaranteeing robust parent container interception. `RadioButton` explicitly performs global synchronous group updates prior to dispatching `Checked` to enforce uniform topological flow. | ||
| - **Execution Phases:** WPF-style two-phase input dispatch (tunneling `Preview*` followed by the paired bubbling event) is implemented by input dispatchers such as `TuiWindow.ProcessKey` (and the console mouse input manager): they raise the corresponding `Preview*` tunneled routed event first and, if it is not handled, then raise the paired bubbling event. Each individual routed event is delivered via `UIElement.RaiseEvent`, which builds the route by walking `Parent` references into an `ArrayPool<UIElement>` buffer (O(h) space where h is tree depth, typically avoiding per-call GC allocations after pool warm-up) and then invokes handlers according to the event’s `RoutingStrategy` (Tunnel: root → source, Bubble: source → root, Direct: source only). When `Handled` is true, traversal continues but instance handlers are skipped unless registered with `handledEventsToo = true`. | ||
| - **Execution Phases:** WPF-style two-phase input dispatch (tunneling `Preview*` followed by the paired bubbling event) is implemented by input dispatchers such as `TuiWindow.ProcessKey` (and the console mouse input manager): they raise the corresponding `Preview*` tunneled routed event first and, if it is not handled, then raise the paired bubbling event. Each individual routed event is delivered via `UIElement.RaiseEvent`, which builds the route traversing the visual tree by walking `Parent` references into an `ArrayPool<UIElement>` buffer (O(h) space where h is tree depth, typically avoiding per-call GC allocations after pool warm-up) and then invokes handlers according to the event’s `RoutingStrategy` (Tunnel: root → source, Bubble: source → root, Direct: source only). Setting `e.Handled = true` does **not** terminate the tunnel or bubble traversal loops. It simply prevents subsequent event handlers from executing unless they were specifically registered with the `handledEventsToo = true` flag (e.g. via `AddHandler`), adhering to standard WPF behavior. |
💡 Target: The
DataContextandExecution Phasessections withinREADME.mdand the foundational UI layout code snippet.🎯 Execution: Articulated that
DataContextinherits viaInheritanceParent(mapping toUIElement.Parent) and clarified that local overrides break this tree inheritance. Confirmed thate.Handled = trueonly stops standard handler dispatch (requiringhandledEventsToo = true), but does not terminate the underlying visual tree traversal array loop. Finally, upgradedStackPanel.Childreninitialization to use modern C# collection initializers.📊 Epistemological Impact: Eradicates speculative assumptions about core framework event routing and data binding hierarchies while maintaining modern syntax parity.
🔬 Verification Protocol: Review the updated
README.mdrendering and verify that the providedStackPanelcode snippet is syntactically flawless C# 10+. Note that the snippet was validated natively via compilation.PR created automatically by Jules for task 15275499332975499002 started by @tedd