ReactSplitPanelControl (com.top_logic.layout.react, src/main/java/com/top_logic/layout/react/control/layout/ReactSplitPanelControl.java) hält seine Panes in _children, überschreibt aber weder propagateAttach() noch propagateDetach(). Jeder andere Container mit Kindern tut das: ReactCompositeControl, ReactStackControl, ReactInsetControl, ReactPanelControl, ReactTabBarControl, ReactDeckPaneControl, ReactDialogControl, ReactWindowControl, ReactSidebarControl, ReactDrawerControl, ReactSwitchControl.

Folge

Alles unterhalb eines <split-panel> gilt dauerhaft als nicht angezeigt (ReactControl#isAttached() bleibt false), obwohl es sichtbar ist. Der Javadoc von isAttached() verspricht das Gegenteil:

A control is attached between calls to attach() and detach(). It is detached while it exists in
memory but is not currently displayed (e.g. the inactive child of a one-of-N container like a
sidebar, tab-bar or deck-pane).

Da die meisten Sichten ihren Inhalt in einem <split-panel> anordnen, ist der Attach-Lebenszyklus dort praktisch abgeschaltet:

• addAttachListener(...) / addDetachListener(...) feuern nie — Logik, die daran hängt, läuft dort nicht.
• ReactControl#onAttach() registriert RoutingParticipant`s beim `RouteManager. Unterhalb eines Split-Panels passiert das nicht, eine Tab-Leiste dort schreibt also kein Route-Segment, obwohl ihre Tabs Routen deklarieren.
• ReactTabBarControl.selectTab(...) und ReactSwitchControl rufen content.attach() nur if (isAttached()) auf. Der Inhalt bleibt dort also unattached, und ein detach() beim Wegschalten ist ein No-op.

Wie gefunden

Bei #29404: Die Toolbar-Beiträge eines versteckten Tabs (<form withEditMode="true"> in zwei Tabs ⇒ zwei „Bearbeiten"-Buttons, von denen einer ein unsichtbares Formular bearbeitet) sollten an Attach/Detach gekoppelt werden — FormElement.contributeEditCommands(...) und contributeFormCommands(...) melden ihre Commands heute bei der Erzeugung an und erst bei der Entsorgung ab. Das war nicht möglich, weil im Showcase (switch-demo.view.xml) die Tab-Leiste in einem <split-panel> sitzt und dort nie ein Attach stattfindet. Umgangen wurde es mit einem weiterleitenden Command-Scope pro Tab (ForwardingCommandScope, TabBarElement, TabDefinition.withActivation(...), ReactTabBarControl).

Vorschlag

1. propagateAttach() / propagateDetach() in ReactSplitPanelControl implementieren (an alle Panes weiterreichen).
2. Danach die Toolbar-Beiträge in FormElement generell an Attach/Detach koppeln statt an Erzeugung/Entsorgung. Der Sonderweg über ForwardingCommandScope im TabBarElement kann dann entfallen, und das Problem ist für jeden „einer von N"-Container gelöst, nicht nur für Tabs.

Zu klären

• Routing: Mit (1) registrieren sich `RoutingParticipant`s unterhalb von Split-Panels erstmals. Tab-Wechsel dort würden dann die URL mitschreiben. Das ist vermutlich das gewollte Verhalten, ändert aber bestehende URLs — vor der Umsetzung prüfen.
• Kollabierte Panes: Entscheiden, ob ein kollabiertes Pane als angezeigt gilt oder detached sein soll.