Rails Dashboard-Design: eine Controller-Aktion pro div

StackOverflow https://stackoverflow.com/questions/908520

Frage

Ich bin die Umsetzung ein Dashboard als relativer Neuling Rails (mehr eine Infrastruktur Typ). Das Armaturenbrett aus mehreren Seiten bestehen, jede Seite davon enthält mehrere Diagramme / Tabellen / etc. Für Modularität, möchte ich es so einfach wie möglich sein, um neue Diagramme hinzugefügt werden sollen oder Blick auf die Daten ändern.

Sprechen Sie eine Seite 5 verschiedene Diagramme hat. Ich könnte der Controller-Lookups 5 separate Daten haben, halten alle relevanten Daten in Instanzvariablen und 5 partials machen, von denen jede Teilmengen der Daten berühren. Aber es scheint, modularer eine „Index“ Controller-Aktion zu haben, die machen hat eine Reihe von div-Tags, und für jedes div gibt es eine andere Controller-Aktion, die den Daten-Lookup tut und hat eine zugehörige Ansicht teilweise verantwortlich für die Ansicht, dass die Verwaltung von Daten innerhalb des div.

Also, wenn ich zeige die Website-Dashboard-Seite, die zwei Graphen hat, website/index website/graph1 und website/graph2 verwenden würde, um die Daten für jeden zu sehen und dann _graph1.html.erb und _graph2.html.erb würde die Controller-Daten verwenden, um divs "graph1" ausfüllen und "graph2", etc .

Ist das das richtige Design, und wenn ja, was ist der einfachste Weg, dies zu erreichen? Ich habe eine Annäherung remote_function mit :action => "graph1" mit divs zu füllen, aber ich bin nicht zu 100% zufrieden. Ich vermute, ich bin fehlt etwas einfacher, dass Rails für mich tun wird.

War es hilfreich?

Lösung

Version 1:

Einfache Methode, die ich tatsächlich in der Produktion verwendet habe: iframes

.

Die meiste Zeit Sie eigentlich nicht, wenn die Seite auf einmal macht und direkt vom Server, und in der Tat ist es besser für sie versetzt zu laden.

Wenn Sie gerade ein iframe src'd zur Show Aktion des Controllers fallen, haben Sie eine sehr einfache Lösung, die keine direkte Quer Controller Wechselwirkungen erfordert.

Pro:

  • kinderleicht
  • arbeitet mit bestehenden Show Aktionen usw.
  • könnte sogar schneller sein, je nach Einsparungen w / parallel vs sequenziellen Zugriffe und Speicherauslastung usw.

Nachteile:

  • Sie können nicht immer leicht speichern Sie die Seite zusammen mit dem, was-it-is
  • wird iframes brechen aus der JavaScript-Namensraum der Host-Seite, so dass, wenn sie verlangen, dass, müssen Sie möglicherweise ihr ihr eigenes minimalistisches Layout geben; sie werden auch nicht möglich sein, die umgebende Seite außerhalb ihres iframe beeinflussen
  • möglicherweise langsamer, je nach Ping-Zeit usw.
  • Potential n + 1 Effizienz Fehler, wenn Sie viele solcher Module auf einer Seite
    • haben

Version 2:

Machen Sie dasselbe mit JS ruft ein div mit einem Teil zu ersetzen, à la: 

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

Wie oben, außer:

Pro:

  • verriegelt nicht in ein iframe, etc also Aktien JS Kontext
  • bessere Handhabung von Fehlerfällen erlaubt

Con:

  • erfordert JS und Platzhalter divs; ein wenig komplex

Version 3:

eine ganze Reihe von partials Rufen. Es wird kompliziert zu tun, dass, wenn Sie über Dinge wie Armaturenbretter reden, wo die einzelnen Module erhebliche Mengen an Setup-Logik haben, aber.

Es gibt verschiedene Möglichkeiten, dies zu umgehen, indem diese Dinge in ‚Mixins‘ oder dergleichen zu machen, aber IMO sind sie irgendwie kludgy.

ETA: Die Art und Weise über Mixins zu tun ist, zu schaffen, was im Wesentlichen eine Bibliotheksdatei, die Ihr Modul-Controller implementiert Setup-Funktionen, beinhaltet, dass, wo immer etwas, das nennt ‚em verwendet wird, und ruft‘ em

.

Dies hat jedoch Nachteile:

  • Sie müssen wissen, was Top-Level-Controller-Aktionen auf den Seiten führen, die die Module (die Sie vielleicht nicht leicht, wenn diese sind wirklich widgety Dinge, die am ganzen Körper, zum Beispiel Benutzerpräferenz abhängig erscheinen könnten) enthalten
  • sie nicht wirklich wirken als vollwertiges Controller
  • es vermischt sich noch viel Logik, wo Ihre Halte Sache über die Dinge zu wissen, braucht es hält
  • Sie können nicht einfach in seine eigene Steuerung getrennt werden müssen, weil sie in einer Bibliothek-Typ Datei / mixin
    • sein muss

Es ist möglich, Methoden in einer Steuerung von einem anderen Controller zu nennen. Aber es ist ein großer Schmerz in dem Arsch, und eine wichtige Flickschusterei. Das einzige Mal, sollten Sie dies tun, denken Sie daran, wenn a) sie beide unabhängig notwendigen Steuerungen in ihren eigenen Rechten sind, und b) es hat ganz am hinteren Ende funktionieren.

Ich habe dies einmal zu tun - vor allem, weil Refactoring den Grund dafür noch mehr Schmerz war -. Und ich verspreche, Sie nicht wollen, dorthin zu gehen, es sei denn, Sie müssen

Zusammenfassung

Die beste Methode IMHO ist das erste, wenn Sie komplex genug, um Dinge, die sie erhebliche Setup erfordern - eine einfache iframe, die das Modul zeigt, einen Parameter übergeben, es zu sagen, ein ultraminimalist Layout zu verwenden (nur CSS + JS-Header), weil es nicht als seine eigene Seite angezeigt wird.

Auf diese Weise können Sie die Dinge halten, völlig unabhängig, funktionieren mehr oder weniger, als ob sie ganz normale Controller der eigenen (anders als die Layout-Einstellung) waren, erhalten normale Routen, etc.

Wenn Sie nicht signifikant Setup brauchen, dann benutzen Sie einfach partials, und übergeben, was auch immer sie brauchen, als eine lokale Variable. Dies startet fragile zu erhalten, wenn Sie in Dinge wie n + 1 Effizienz Wanzen laufen, obwohl ...

Andere Tipps

, warum Sie Apotomo einen Versuch nicht geben, das ist Stateful-Widgets für Rails:

ein Tutorial, wie ein einfaches Armaturenbrett bauen

Sie können dies erreichen, indem sie mit

render_output = render: action => "graph2"

Aber mich persönlich würde wahrscheinlich den Code entweder in einem gemeinsamen Helfer wickeln oder schreiben Sie besitzen „lib“ unter dem lib den Code mit einer gemeinsamen Vorlage wiederzuverwenden. Denken Sie daran, dass, wenn Sie Ihre route.rb Datei ändern definiert jede öffentliche Methode von

zugänglich ist

/ controller / action /: id

Denken Sie auch an das Layout für die Funktion deaktivieren: layout => nil (oder geben Sie an der Oberseite des Controllers Layouts "Graph",: außer => [ "graph2"]

Prost

Christian

Ich bin nicht bekannt, dass spezielle Rails Tricks für dieses Ziel zu erreichen, ohne Verwendung von AJAX in der Art und Weise Sie skizziert haben.

Der einfachste Weg, um die Modularität Sie suchen zu bekommen, ist jene Teile der Controller-Code in separate Methoden zu setzen (zB set_up_graph1_data, set_up_graph2_data, etc.), die Sie einfach von Ihrem index Aktion aufrufen, um die Variablen für die Ansicht einzurichten.

Sie können diese Methoden in ApplicationController setzen, wenn Sie sie auf mehrere Controller verfügbar sein soll.

Als Randbemerkung, früh, Rails hat verwendet, um eine Funktion zu haben, ‚Komponenten‘ genannt, die Sie erlauben würden, genau das zu tun, was Sie hier sind zu fragen, ohne AJAX zu verwenden. Aus Ihrer Sicht könnte man einfach einen anderen Controller-Aktion machen, Inline. Allerdings wurde diese Funktion für Leistung und Design-Philosophie Gründen entfernt.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top