À faire et à ne pas faire : Contexte Webdynpro.

Il me semble que ces règles visent à améliorer les performances.

J’ai quelques remarques sur quelques-unes de ces règles:

• Sans aucune exigence (utilisation dans plusieurs contrôleurs), ne créez pas de contexte au niveau du contrôleur de composants, si nécessaire, créez des contextes locaux, par exemple dans les vues

Le contrôleur de composants est votre concentrateur central pour votre contexte. Si, à tout moment, vous avez un nœud de contexte partagé sur plusieurs vues, vous devez le créer dans le contrôleur de composants et le mapper à d’autres vues.

Des nœuds spécifiques à une certaine vue peuvent être créés directement sur le contexte de la vue, mais pour plus de lisibilité et d’uniformité, je choisis souvent de centraliser tous mes nœuds de contexte et méthodes d’alimentation dans le contrôleur de composants.

• Utilisez des nœuds singleton si des imbrications (détail maître) sont nécessaires

Les nœuds singleton sont bons pour les performances, car vous ne gardez qu’une instance de votre nœud en mémoire, plutôt que d’avoir plusieurs instances pour chaque objet parent (inactif). Cependant, vous feriez mieux de savoir ce que vous faites car si vous vous trouvez dans une situation où vous avez besoin de plusieurs éléments parents actifs (répéteur de lignes, tables imbriquées, arbres, tables multisélections…) le nœud singleton videra votre application.

Si vous ne connaissez pas bien le principe des nœuds singleton ou si les performances ne sont pas un problème, n’utilisez pas de nœuds singleton.

• N’utilisez pas d’attributs dynamiques (IF_WD_CONTEXT_NODE_INFO-> ADD_ATTRIBUTE)

Si vous pouvez utiliser des attributs de contexte définis statiquement, utilisez des attributs statiques. Il y aura cependant des situations dans lesquelles vous devrez créer dynamiquement votre contexte. Dans ces cas, vous n’avez pas d’autre choix que d’ajouter des attributs dynamiques. Je suis cependant d’accord sur le fait que vous devez éviter autant que possible la programmation de contexte dynamique (et la programmation de vue dynamique).

• Utiliser des données avec une structure de contexte pour BIND_TABLE

Pas une exigence difficile, en interne, les opérations de liaison utilisent un mouvement correspondant et conservent la table d’origine dans une variable d’ombre. Bien que le mouvement correspondant soit apparemment mauvais pour les performances. (Je dis apparemment, parce que j’ai fait des tests de moi-même et que je n’ai trouvé aucune différence significative)

• Mettre à jour le contexte uniquement si les données doivent réellement être mises à jour

Dépend de ce que vous voulez dire par mise à jour?

• Ne créez pas de longues chaînes de mappage de contexte.

?

• Utilisez les fonctions du journal des modifications de contexte pour détecter les entrées utilisateur. Cela présente des avantages de performances particuliers alors qu’un utilisateur de l’application ne modifie qu’une petite quantité de données dans une vue tout en affichant une grande quantité de données mixtes.

Vrai. Le changelog de contexte peut être très puissant lorsqu’il est utilisé de manière dynamique.

Mais c’est aussi très avancé. J’ai un extrait pour passer en revue tous les changements dans un contexte, affecter les données à la variable appropriée dans la classe d’assistance (champ dans la structure, ou champ dans une ligne dans une table interne) et appeler dynamiquement une méthode de gestionnaire (le cas échéant). J’ai partagé cet extrait avec beaucoup de développeurs hautement qualifiés. À ce jour, seuls 2 comprenaient réellement ce qu’il faisait et étaient capables de l’appliquer sur leurs propres composants.

Les règles que vous mentionnez sont assez intéressantes, mais comme Steve l’a mentionné, vous voudrez peut-être élaborer sur le but et l’idée sous-jacente.

Santé!