Theme-Component v Plugin: Was ist der Unterschied

Entwickler
22

Danke, @tshenry. Ich bin mir nicht sicher, warum der Code für den Gruppenbesitzer bei mir nicht funktioniert hat – wahrscheinlich liegt es an meiner Plugin-Konfiguration.

Ich habe festgestellt, dass der AJAX-Ansatz als „MVP“-Methode funktioniert. Übrigens: Ich glaube, man kann eine API-Anfrage an [forum-url]/groups.json stellen, um alle Gruppen der Seite abzurufen, und dann einfach durch die Ergebnisse iterieren. Es sind also keine mehreren Aufrufe nötig.

Ich wollte folgende Fragen stellen:

– Beim AJAX/JSON-API-Ansatz: Weißt du, wie man dafür sorgt, dass eine Funktion nur ausgeführt wird, wenn ein Benutzer eine bestimmte Seite aufruft? Aktuell, wenn ich den AJAX-Code im </head>-Bereich meines angepassten Dashboards platziere, funktioniert es zwar, aber es wird bei jedem Laden der Seite ausgeführt (während ich es nur beim Laden der Gruppenindexseite ausgeführt haben möchte).

– In meinem Fall nutze ich AJAX derzeit vor allem, weil ich nicht nur die Gruppenbesitzer anzeigen muss, sondern auch einige weitere neue Merkmale einer Gruppe, die ich hinzufüge. Das wären wie benutzerdefinierte Felder der Gruppe, die ich abrufen und anzeigen möchte. Derzeit ist die „MVP“-Version (während ich noch lerne, wie die Discourse-Codebasis funktioniert), diese Daten in einer separaten, nicht-Discourse-Datenbank zu speichern, von der ich sie abrufe und auf der Gruppenindexseite anzeige.

Offensichtlich wäre die sauberere Lösung, die benutzerdefinierten Merkmale direkt in der Discourse-Datenbank bei den Gruppen zu speichern und diese dann abzurufen. Ich versuche nur abzuschätzen, welcher Aufwand dafür nötig wäre. Würde das bedeuten, dass ich viele Discourse-Dateien (Controller, Modelle, Vorlagen) neu bearbeiten müsste?

23

Ich kann es, sobald ich Zeit habe, in ein kleines GitHub-Repository stellen.

Ich glaube nicht, dass dies Zugriff auf die Inhaberdaten gewährt, aber vielleicht übersehe ich etwas.

Bezüglich deiner Fragen:

  1. Die von mir verlinkte Theme-Komponente macht Ähnliches, um sicherzustellen, dass der Ajax-Aufruf nur auf /latest oder der Startseite ausgeführt wird. Ich würde versuchen, auf dieser Idee aufzubauen: discourse-featured-topics/common/head_tag.html at ddf3d7e003423e2e5f83446a80cab78d51f09e2d · awesomerobot/discourse-featured-topics · GitHub

    Falls du es noch nicht getan hast, schau dir unbedingt auch folgendes an: Developing Discourse Themes & Theme Components

  2. Es gibt kein eingebautes Konzept für benutzerdefinierte Gruppenfelder, wie es bei benutzerdefinierten Benutzerfeldern der Fall ist. Ich glaube, du müsstest ein Plugin entwickeln, das alle notwendigen Komponenten hinzufügt, damit das funktioniert.

24

Du hast recht. Ich habe das vergessen – das ist etwas, das ich aktuell in einer separaten Datenbank speichere und über AJAX (und ein bisschen Magie) abrufe.

Tolle Idee – ich sehe, was du mit if ((url == "/") || (url == "/latest") ) in diesem Repository gemacht hast. Ich kann etwas Ähnliches umsetzen.

Ja – ich habe diesen Leitfaden ebenso wie die anderen, die ich finden konnte, durchgearbeitet. Es ist ein großartiger Leitfaden, aber ich finde den Übergang von diesem Leitfaden (und anderen auf Meta) zur Umsetzung solcher Anpassungen schwierig. Diese Anpassungen erfordern, soweit ich das beurteilen kann, ein tiefes Verständnis dafür, wie Vorlagen, Controller und Modelle im Discourse-Codebase zusammenhängen.

Ausblick

Ember mag ein großartiges System für die Erstellung performanter Apps sein, aber ich finde es schwierig, herauszufinden, wie die verschiedenen Dateien miteinander verknüpft sind. Zum Beispiel sagt dir das Finden der richtigen Vorlage in einer Ansicht im GitHub-Repository nicht viel darüber aus, welche anderen Vorlagen damit verknüpft sind, und schon gar nicht, welche Controller und anderen Modelle relevant sein könnten. Es ist möglich, aber es geht langsam, und man muss diese Zusammenhänge wirklich verstehen, um solche Anpassungen vornehmen zu können.

In Angular sind als alternative Methode die Teile der View-Komponenten normalerweise zusammen mit einer HTML-, TypeScript- und CSS-Datei gruppiert, und andere relevante Dateien sind in diesen Dateien klar gekennzeichnet (so werden im TypeScript-File genutzte Services identifiziert und im HTML-File klar markiert, welche anderen Komponenten eingefügt werden). Soweit ich das überblicke, funktioniert die Discourse-Ember-Struktur nicht so (nicht, um diese Struktur zu kritisieren – es ist eine sehr stabile, hochperformante App – man muss sich einfach daran gewöhnen).

Daher nutze ich Dinge wie AJAX, um zum gleichen Ergebnis zu kommen, während ich weiterhin versuche zu verstehen, wie die Discourse-Komponenten zusammenhängen.