enhancement
major
minor
major
minor
major
#29607
TL Views: a display target reveals a tab inside a pushed frame (a <show> is located within the view shown before it)
Problem
Display targets (#29532) reveal a mounted view by walking its mount path from the root, and push an unmounted view as a frame onto the stack of the previously shown view. The issue tracker tl-dev declares for tl.dev:Milestone the chain project list → project home (project.view.xml, a frame of the Projects stack, with <bind channel="project"> and <bind channel="selectedMilestone">). The project home is a <tab-bar> with the tabs Board, Tickets, Roadmap, …; the milestone table sits on the Roadmap tab.
Following a milestone link pushes the project home and writes the milestone into selectedMilestone, but the page opens on the Board tab (its active-tab): the Roadmap tab, where the selected milestone is displayed, is not revealed.
A reveal can show views and write channels, nothing else, so whatever is to be revealed needs a name — and the inline content of a tab has none. Giving it one is the application's business: the content of the tab moves into a view file of its own, and the target names that view. Tabs themselves are already covered: TabBarElement reports every tab as a content group keyed by the tab id, so a <view-ref> on a tab is recorded at that key, and the tab's display sits at exactly that place.
What prevents it is only the frame in between. ViewMounts derives the mount paths from the content groups walked from the root view, and TileStackElement reports its initial view alone. Nothing inside a frame view is therefore reachable from the root, and a <show> naming a view on a tab of the project home finds no mount path at all: it is pushed as yet another frame instead of revealing the tab.
Lösung
A <show> is looked up within the view that the <show> before it displayed, and only then, as before, within the window as a whole.
The frame holding the tab bar is pushed by the preceding <show> anyway, so the following one only has to be located inside that frame view — which a scan of the frame view answers, from the same cache the scan of the root view uses. ObjectNavigation therefore remembers the place of the view each <show> displayed, in the drilled-down case as well (the frame's place comes from the TileStackScope, which knows where its stack sits and at which position the frame was pushed), and starts the reveal walk of the following <show> there, with the mount path the frame view's own scan answers.
Nothing changes in the scan, in the elements, or in the reveal protocol: a tab, a sidebar item or a master-detail side inside a pushed frame is revealed by the very mechanism that already reveals it outside one, and this composes to any depth (a frame inside a tab inside a frame).
Two alternatives were considered and rejected:
- Frames as mounts (TileStackElement reporting its declared <frame> views as keyed content): the frames of a stack are addressed by their position, because the same view may sit on one path several times. A statically scanned step could only name the view and would therefore never match the place a frame is registered at. Revealing a frame would in addition have to carry the channel values of the enclosing <show> into the reveal walk, which the protocol deliberately does not do.
- A channel for the active tab (<tab-bar> mirroring its active tab in a channel that a <bind> of a target could set): unnecessary once the content of the tab has a name of its own, and it would make the way an object is revealed depend on whether its view happens to sit on a tab.
Documented in docs/faq/react-view-layer.md, and shown in the React demo's project drill-down: the milestones frame becomes the project home, a <tab-bar> with an overview tab and a milestone tab whose table moved into a view of its own, so that following a milestone link lands on that tab.
Nebenbefund
The React demo's display target for tl.accounts:Person binds the channel selectedPerson of demo/tiles-demo/overview.view.xml, which that view never declared: every start of the application logged a configuration error, and the account the target displays was not marked in the list it is shown in. The view now declares the channel and its table publishes the selected row on it, as the project list does.
That the nodes of a <tree> are never offered as links, although the display targets declare where their objects are shown, is a defect of its own: #29620.