Reactive desktop frames

Statut documentaire : guide — voir Maturité et preuves.

Un reactive desktop frame n’est pas un simple conteneur de layout. C’est une frontière réactive locale capable d’héberger des vues enfants, recevoir un contexte, router des événements, réagir à l’état des DataSets, mettre à jour une preview et coordonner un shell de workflow.

Rôles

Une frame réactive peut jouer les rôles d’hôte dynamique, frontière de contexte, récepteur d’événement, routeur, coordinateur sensible aux DataSets, surface de preview ou shell de workflow. Elle reçoit un contexte, par exemple un input cursor, mais ne possède pas l’objet métier.

Pattern hôte

Utiliser une région nommée pour charger ou changer une vue enfant tout en gardant le reste de la page stable. L’application exprime une intention comme ShowView avec frame cible, vue et contexte en paramètres ; le composant émetteur n’a pas besoin de connaître le rendu concret.

Routage parent/enfant

Pour la coordination descendante, la frame notifie ses enfants avec un événement visuel sémantique. Pour la remontée, un enfant distribue vers le ParentPageControler. Éviter les références directes et dures entre composants enfants et objets d’implémentation parents.

Réaction aux DataSets

Un événement DataSet peut mettre à jour l’état local de la frame, les surfaces de statut, la visibilité, les actions disponibles ou les enfants. Il s’agit de logique d’état de vue. La règle métier doit déjà être portée par le modèle ou une surface calculée.

Refresh et recomputation

Pattern avancé utile :

interaction enfant
 -> événement visuel parent
 -> notification des enfants concernés
 -> refresh d’un DataSet calculé
 -> mise à jour de l’état page/frame

Cela donne une interface vivante sans reconstruire toute la page.

Protection contre les boucles

Protéger les chaînes réactives : tester le sender avant refresh, éviter qu’un DataSet se rafraîchisse en réponse à son propre événement, distinguer refresh demandé/terminé, permettre aux enfants de stopper la propagation, debouncer les événements fréquents et garder les événements applicatifs idempotents si possible.