web-dev-qa-db-fra.com

Comment fonctionne le cycle de vie des contrôles UI5?

Quelqu'un peut-il donner une explication plus détaillée sur le cycle de vie des événements par défaut d'un contrôle UI5? Je sais qu'il y a cette page sur la documentation qui donne un aperçu d'un cycle de vie de Control, cependant, je pense qu'il est très bref et voulait quelque chose de plus détaillé. Quelqu'un peut-il lister l'ordre des événements d'un contrôle et expliquer ce que fait chaque événement?

sapui5
9
André Shevantes

Tu as tout à fait raison. Les détails d'un cycle de vie de contrôle et les détails d'implémentation sont très bien cachés dans les documents. Je vais essayer de résumer ma compréhension jusqu'à présent pour vous.

Le cycle de vie d'un contrôle est principalement déterminé par:

  • init : Votre petit contrôle est né! La fonction est appelée par le framework lors de l'exécution du constructeur. Faites vos trucs d'initialisation ici.
  • onBeforeRendering : appelé par le framework avant le démarrage du rendu du contrôle. Se déclenche avant chaque (re) rendu.
  • onAfterRendering : appelé par le framework une fois le rendu du contrôle terminé. Se déclenche après chaque (re) rendu.
  • exit : RIP petit contrôle! Nettoie l'instance d'élément avant sa destruction. Appelé par le cadre. Faites votre ménage ici. Btw: Si vous devez détruire explicitement un contrôle/élément, vous devez appeler destroy et ne pas quitter directement.

Voici un exemple d'implémentation avec quelques exemples d'utilisations pour les différents crochets:

sap.ui.core.Control.extend("a.sample.Control", {
  init : function() {
    // instantiate a sub-control
    this._btn = new sap.m.Button(); 
  },

  onBeforeRendering : function() {
    // deregister a listener via jQuery
    this.$("subelement").off("click", this.subElementClick);
  },

  onAfterRendering : function() {
    // register a listener via jQuery on a sub-element
    this.$("subelement").on("click", this.subElementClick);
  },

  subElementClick : function() {
    // do stuff
  },

  exit : function() {
    // clean up sub-controls and local references
    this._btn.destroy();
    delete this._btn;
  }

});

Pourquoi ne devrais-je pas faire mes trucs init dans mon constructeur?

Il existe un constructeur UI5 de base dans ManagedObject . Il "prépare" votre objet UI5 pour vous et appelle ensuite votre fonction init. Cela signifie que dans votre init, tous les paramètres seront déjà appliqués pour vous et vous pouvez accéder aux propriétés et aux agrégations comme d'habitude.

Pourquoi ne devrais-je pas appeler le rendu?

Le rendu SAPUI5 est intelligent en ce sens qu'il regroupe et optimise les rendus en file d'attente. Par conséquent, vous ne devez jamais appeler rerender directement mais utiliser à la place invalidate pour marquer un contrôle pour le rendu.

HF

Chris

21
cschuff

UI5 fournit des crochets de cycle de vie prédéfinis pour la mise en œuvre du contrôleur . Vous pouvez ajouter des gestionnaires d'événements ou d'autres fonctions au contrôleur et le contrôleur peut déclencher des événements, pour lesquels d'autres contrôleurs ou entités peuvent s'enregistrer.

UI5 fournit les crochets de cycle de vie suivants:

  • onInit(): Appelé lorsqu'une vue est instanciée et que ses commandes (si disponibles) ont déjà été créées; utilisé pour modifier la vue avant qu'elle ne s'affiche pour lier les gestionnaires d'événements et effectuer une autre initialisation unique

  • onExit(): appelé lorsque la vue est détruite; utilisé pour libérer des ressources et finaliser les activités

  • onAfterRendering(): appelé lorsque la vue a été rendue et, par conséquent, son code HTML fait partie du document; utilisé pour effectuer des manipulations post-rendu du HTML. Les contrôles SAPUI5 obtiennent ce hook après avoir été rendus.

  • onBeforeRendering(): appelé chaque fois que la vue est rendue, avant l'appel du rendu et le HTML est placé dans l'arborescence DOM .

Source: i5.sap.com/#/topic/121b8e6337d147af9819129e428f1f75

1
ümit duran