Quels sont les modèles de conception trouvés dans les modules contribués importants?

En plus de présentation abstraction de contrôle et d' autres motifs qui sont utilisés dans le noyau Drupal , sont - il d'autres modèles de conception utilisés en bonne place dans les plus modules ont contribué populaires telles que les vues, CCK, et fonctionnalités?

— Matt V.
source

Comme indiqué dans la FAQ , "Vous ne devez poser que des questions pratiques et fiables basées sur les problèmes réels auxquels vous êtes confronté. Les questions ouvertes et bavardes diminuent l'utilité de notre site et repoussent les autres questions de la première page."

— kiamlaluno

cela pourrait être un bon sujet wiki communautaire

— Chaulky

Le wiki communautaire n'est plus utilisé pour les questions qui ne sont pas acceptables ou qui sont à la limite. Voir L'avenir du wiki communautaire .

— kiamlaluno

D'un autre côté, je pense que c'est un sujet intéressant. Suggestion pour une meilleure question: "Existe-t-il un modèle de conception qui peut résoudre le problème X?". Parce que c'est à cela que servent les modèles de conception pour résoudre un problème, ils ne doivent pas être utilisés uniquement pour qu'ils soient utilisés.

— Berdir

@kiamlaluno, je dirais que la question n'est pas sans réponse, bavarde ou impraticable, bien qu'elle puisse sans doute être ouverte. Mon objectif en posant la question est de mieux comprendre comment les modèles de conception sont utilisés, dans un code que je connais un peu.

— Matt V.

Un point de départ est le noyau lui-même et les modèles exposés à contrib. - un excellent article de Larry Garfield (Crell) peut être trouvé dans un article Drupal Watchdog .

Observateurs, visiteurs et toms voyants

Drupal est en fait construit sur les modèles jumeaux d'Observateur et de Visiteur, bien qu'il ne les appelle pas par leur nom. Au lieu de cela, il les appelle des crochets. hook_node_load(), hook_user_login()et ainsi de suite sont, en substance, des observateurs sur les nœuds et les utilisateurs. hook_form_alter(), hook_node_view()et ainsi de suite sont essentiellement des visiteurs. Parce que Drupal ne fait pas de différence entre les deux, certains crochets pourraient sans doute être considérés comme les deux modèles, mais le principe est le même.

Usines et commandes

Il existe plusieurs variantes du modèle Factory, mais elles se résument toutes à la même idée: un objet, un client, demande à un autre objet, une usine, une implémentation appropriée d'un morceau de logique, mais ne se soucie pas de savoir de quoi il s'agit. . C'est à l'usine de décider. Considérez la db_insert()fonction, dont les bits importants sont présentés ci-dessous:
   function db_insert($table, array $options = array()) {
       // ...
       return Database::getConnection($options['target'])->insert($table, $options);
     }
La Database::getConnection()méthode est une fabrique qui renvoie un objet de connexion approprié pour ce site.

Injection de dépendance du docteur Drupal

Dans Drupal 6, le système de menus a été vidé et réécrit pour être un processus en plusieurs étapes. Nous allons maintenant implémenter le même rappel de page comme ceci:
   function example_menu() {
       $items['node/%node/example'] = array(
         'page callback' => 'example_page',
         'page arguments' => array(1),
         // ...
       );
       return $items;
     }

     function example_page($node) {
       // Do useful stuff here.
     }
Dans cette nouvelle configuration, le routeur de menu devient plus complexe. En retour, cependant, le rappel de page obtient le nœud dont il dépend lui est transmis, c'est-à-dire qu'il y est injecté. Cela nous donne un certain nombre d'avantages.

Allez pour Broke (r)

Une approche courante consiste à varier l'idée d'un courtier ou d'un médiateur. Dans cette conception, un objet ne demande pas directement d'informations à un autre objet. Au lieu de cela, il demande à un objet intermédiaire, qui pourrait y avoir été injecté, de faire une telle demande en son nom. Bien que cela signifie toujours que le premier objet doit demander activement des informations, il n'est que étroitement couplé à l'objet médiateur et non à la myriade d'autres objets dont il peut avoir besoin de demander des informations. Cela signifie que si ces autres systèmes changent, nous n'avons qu'à mettre à jour le médiateur, pas tous les systèmes qui le touchent.

— kiamlaluno
source