Rails conception de tableau de bord: une action de contrôleur par div

Question

Je suis un tableau de bord comme la mise en œuvre d'un débutant Rails relatif (plus d'un type d'infrastructure). Le tableau de bord se compose de plusieurs pages, dont chaque page contient plusieurs graphiques / tableaux / etc. Pour la modularité, je veux que ce soit aussi facile que possible d'ajouter des graphiques ou changer de vue des données.

Dites une page a 5 cartes différentes. Je pourrais avoir le contrôleur faire 5 recherches de données distinctes, tenir toutes les données pertinentes dans les variables d'instance, et rendre 5, chacun partials des sous-ensembles touchent des données. Mais il semble plus modulaire d'avoir un « index » l'action du contrôleur dont le rendu a un tas de divs, et pour chaque div une autre action de contrôleur qui fait la recherche de données et a une vue associée partielle en charge de la gestion de la vue de ces données dans le div.

Donc, si je montre la page du tableau de bord de site Web qui a deux graphiques, website/index utiliserait website/graph1 et website/graph2 pour rechercher les données de chaque puis _graph1.html.erb et _graph2.html.erb utiliserait les données du contrôleur pour remplir divs "graph1" et "graph2", etc. .

Est-ce la bonne conception, et si oui, quelle est la meilleure façon d'y arriver? J'ai une approximation à l'aide remote_function avec :action => "graph1" pour remplir divs, mais je ne suis pas 100% satisfait. Je pense que je me manque quelque chose plus facile que Rails faire pour moi.

Answer 1

Version 1:

Méthode simple que je l'ai effectivement utilisé dans la production: iframes

.

La plupart du temps vous ne se soucient pas vraiment si la page rend à la fois direct et du serveur, et bien il vaut mieux qu'il se charge titubant.

Si vous laissez tomber juste un iframe src'd à l'action show du contrôleur, vous avez une solution très simple qui ne nécessite pas les interactions entre contrôleurs directs.

Pro:

• mort facile
• travaille avec des actions existantes montrent etc
• pourrait même être plus rapide, en fonction des économies w / parallèle vs demandes successives et de la charge de la mémoire etc

Moins:

• vous ne pouvez pas toujours facilement enregistrer la page en même temps que tout-it-est
• iframes va sortir de l'espace de noms javascript de la page d'accueil, donc s'ils ont besoin que vous pourriez avoir besoin de leur donner leur propre mise en page minimaliste; ils seront également pas en mesure d'influer sur la page environnante en dehors de leur iframe
• pourrait être plus lent, en fonction du temps de ping etc
• potentiel n + 1 bug d'efficacité si vous avez beaucoup de ces modules sur une page

Version 2:

Faites la même chose en utilisant appelle JS pour remplacer un div avec un partiel, à la:

<div id="placeholder">
<%= update_page {|page| page['placeholder'].replace with some partial call here } %>

Comme ci-dessus, sauf:

Pro:

• ne se verrouille pas dans une iframe, actions ainsi contexte JS etc
• permet un meilleur traitement des cas de défaillance

Con:

• nécessite divs JS et espace réservé; un peu plus complexe

Version 3:

Appeler un tas de partials. Il se complique de le faire une fois que vous parlez des choses comme des tableaux de bord où les modules ont des quantités importantes de la logique de configuration, cependant.

Il existe différentes façons de contourner ce problème en faisant ces choses dans « mixins » ou similaires, mais ils sont un peu l'OMI kludgy.

ETA: La façon de le faire via mixins est de créer ce qui est essentiellement un fichier de bibliothèque qui implémente vos contrôleurs de modules de fonctions de configuration, comprennent que chaque fois que quelque chose qui appelle « em est utilisé, et appeler » em

.

Cependant, cela a des inconvénients:

• vous devez savoir ce que les actions du contrôleur de haut niveau se traduira par les pages qui contiennent ces modules (qui vous ne pourriez pas facilement, si ce sont vraiment widgety choses qui pourraient apparaître sur tout, par exemple la préférence de l'utilisateur dépendant)
• il n'agit pas vraiment comme contrôleur à part entière
• il entremêle encore beaucoup de logique où votre chose holding a besoin de connaître les choses qu'il tient
• vous ne pouvez pas facilement être séparé en son propre contrôleur, parce qu'il a besoin d'être dans un fichier de type bibliothèque / mixin

Il est possible d'appeler des méthodes dans un contrôleur d'un autre contrôleur. Cependant, il est une douleur importante dans le cul, et une bidouille majeure. Le seul moment où vous devriez envisager de le faire est si a) ils sont tous les deux contrôleurs indépendamment nécessaires dans leurs propres droits, et b) il doit fonctionner entièrement à l'arrière.

J'ai dû le faire une fois - principalement parce refactoring la raison de ce qui était encore plus d'une douleur -. Et je vous promets que vous ne voulez pas y aller à moins que vous devez

Résumé

La meilleure méthode à mon humble avis est la première si vous avez des choses assez complexes qu'ils nécessitent un réglage important - d'une simple iframe qui affiche le module, le passage d'un paramètre à dire d'utiliser une mise en page de ultraminimalist (juste CSS + têtes JS) parce qu'il est pas affiché comme sa propre page.

Cela vous permet de garder les choses totalement contrôleurs indépendants, fonction plus ou moins comme si elles étaient parfaitement normales de leur (autres que le réglage de la mise en page), préservez routes normales, etc.

Si vous n'avez pas besoin configuration significative, il suffit d'utiliser partials, et passer dans tout ce dont ils ont besoin en tant que variable locale. Cela va commencer à se fragile si vous avez des choses comme n + 1 bugs efficacité, mais ...

Answer 2

pourquoi ne pas vous donner Apotomo un essai, c'est des widgets pour Rails stateful:

Un tutoriel comment construire un tableau de bord simple

Answer 3

Vous pouvez le faire en utilisant

render_output = render: action => "graph2"

Mais moi personnellement probablement envelopper le code soit une aide commune ou vous écrire propre « lib » dans le répertoire lib de réutiliser le code avec un modèle partagé. Rappelez-vous que si vous changez votre fichier route.rb toute méthode publique définie est accessible par

/ contrôleur / action /: id

Souvenez-vous également de désactiver la mise en page de la fonction: layout => nil (ou préciser en haut de la disposition du contrôleur "graphique",: sauf => [ "graph2"]

Vive

Christian

Answer 4

Je ne suis pas au courant des astuces Rails spéciaux pour y parvenir sans utiliser AJAX dans la façon dont vous avez décrit.

La façon la plus simple d'obtenir la modularité que vous cherchez est de mettre ces portions de code du contrôleur dans des méthodes distinctes (par exemple set_up_graph1_data, set_up_graph2_data, etc.), que vous appelez simplement de votre action index pour configurer les variables pour la présentation.

Vous pouvez mettre ces méthodes en ApplicationController si vous voulez mettre à la disposition de plusieurs contrôleurs.

Comme une note de côté, au début, Rails a fait utilisé pour une fonctionnalité appelée « composants » qui vous permettra de faire exactement ce que vous demandez ici, sans avoir à utiliser AJAX. De votre point de vue, vous pouvez simplement rendre une autre action du contrôleur, en ligne. Cependant, cette fonction a été supprimée pour des raisons de performance et de la philosophie de conception.