it-swarm.com.de

Wie lautet der Entscheidungsbaum für das Erstellen eines neuen Inhaltsentitätstyps beim aktuellen D8-Status im Vergleich zum Erstellen eines Inhaltstyps für die Inhaltsentität "Knoten"?

Wir haben vier Jahre gesehen und Drupal 8s erste Veröffentlichung seit die akzeptierte Antwort für die Frage geschrieben wurde " Wann ist es angebracht, eine Entität zu erstellen, anstatt nur einen neuen Inhaltstyp hinzuzufügen =? "Und Entitäten sind für Drupal 8) zentraler als in Drupal 7. ( RefB , RefC , RefD )

In dieser neuen Welt Drupal 8) ist der Entscheidungsbaum für das Erstellen eines neuen Inhaltsentitätstyps im Vergleich zu einem neuen Inhaltstyp für die Inhaltsentität vom Typ "Knoten" "?

Beachten Sie bei der Beantwortung einer Antwort Folgendes:

  • Ist ein neuer Inhaltstyp für den Inhaltsentitätstyp "Knoten" in 99% -Situationen im Vergleich zu einem neuen Inhaltsentitätstyp noch geeignet?
  • Enthält der Entscheidungsbaum jetzt mehr, bessere oder klarere Gründe, von der Verwendung des Inhaltsentitätstyps "Knoten" abzuweichen und stattdessen einen neuen Inhaltsentitätstyp zu erstellen? Und wenn ja, was sind sie? Enthalten sie:
    • Performance?
    • Sicherheit/Berechtigungen?
    • Die Anzahl der Module, die mit Inhaltstypen vom Typ Knotenentität und nicht mit anderen Inhaltstypen arbeiten?
  • Basierend auf der zuvor akzeptierten Antwort, auf die oben verwiesen wurde, besteht der einzige allgemeine Grund für die Verwendung eines benutzerdefinierten Inhaltsentitätstyps möglicherweise darin, dass Sie Node Daten, z. B. mit Taxonomiebegriffen, oder andernfalls Knoten kommentieren, zB mit Kommentaren?

Die Modulkompatibilität scheint eine besonders interessante Überlegung für einen Entscheidungsbaum zu sein. Derzeit haben nur wenige der am meisten installierten Module eine Version für 8.x, die nicht nur Alpha, Beta oder RC (ein Release-Kandidat) ist. Und es scheint schwierig zu identifizieren, wie viele von ihnen mit einem neuen benutzerdefinierten Entitätstyp im Vergleich zu einem neuen Inhaltstyp für Knotenentitäten sofort funktionieren. Es scheint kein Projektattribut zu geben, um zwischen solchen zu unterscheiden, die "für Entitäten geschrieben" und "für Knotenentitätstypen geschrieben" sind.

Werfen Sie einen Blick auf pathauto, das derzeit das vierthäufigste installierte Modul von Modulen mit 8.x ist. Leute sind arbeiten hart in einer 8.x-Version, die im Allgemeinen Entitäten und nicht nur Inhaltstypen vom Typ Knoten-Entität unterstützt. Aber was ist mit all den anderen Modulen? Und erfordern Module, die Entitäten unterstützen, im Allgemeinen benutzerdefinierte Inhaltsentitätstypen, um modulspezifische "Hooks" zu haben, bevor das Modul mit ihnen arbeitet? (Im Gegensatz dazu, wie die Module mit neuen Inhaltstypen sofort funktionieren?) Das scheint zu sein die Art von Herausforderung, mit der das Pathauto-Team arbeitet, und vielleicht ist es ein Grund, sich abzuwenden von einem benutzerdefinierten Inhaltsentitätstyp?

Es kann auch erwähnenswert sein, dass Drupal 8 core eine Benutzeroberfläche zum Erstellen neuer Inhaltstypen für die Inhaltsentität vom Typ "Node" enthält, derzeit jedoch keine Benutzeroberfläche zum Erstellen einer neuen Inhaltsentität Typen. ( RefX , RefY , RefZ )

23
Jon Freed

Entscheidungsbaum für die Auswahl zwischen dem Erstellen eines neuen Inhaltstyps vom Typ Knotenentität und einem neuen Inhaltstyp vom Inhalt:

  1. Sind Sie Programmierer oder haben Sie einfachen Zugang zu einem Programmierer?
    • Wenn nein, können Sie derzeit nur noch neue Inhaltstypen für Knotenentitäten erstellen. (Im Kern gibt es keine Benutzeroberfläche zum Erstellen neuer Entitätstypen für Inhalte, und das Modul Entity Construction Kit (ECK) Contrib verfügt derzeit nur über eine Alpha-Version.)
    • Wenn ja, dann weiter ...
  2. Wissen Sie genau, welche Contrib-Module Sie für Ihre Daten nutzen möchten?
    • Wenn nein, besteht die sichere Wette wahrscheinlich darin, nur einen Inhaltstyp für eine Knotenentität zu erstellen.
    • Wenn ja, unterstützen diese Module bereits die benutzerdefinierten Entitätstypen, die Sie in Betracht ziehen, oder sind Sie bereit, sie zu verbessern, damit sie die gewünschte Funktionalität in Ihrem Modul wiederherstellen oder neu erstellen?
      • Wenn nein, ist es möglicherweise am besten, nur einen Inhaltstyp vom Typ Knotenentität zu erstellen.
      • Wenn ja, dann weiter ...
  3. Helfen die tatsächlichen Inhaltsdaten, die von Ihrem Modul aktiviert werden, lediglich dabei, andere Inhaltsdaten zu gruppieren oder zu kommentieren? (Damit es selten alleine betrachtet wird.)
    • Wenn ja, prüfen Sie, ob Ihr Modul den vorhandenen Entitätstypen für Taxonomiebegriffe und -kommentare entspricht. Wenn dies der Fall ist, kann ein neuer Entitätstyp eine sichere Wette sein.
    • Wenn nein, dann weiter ...
  4. Können Sie klar formulieren, warum ein neuer Inhaltstyp vom Typ Knotenentität für Sie nicht funktioniert?
    • Wenn nein, ist es sicher, dass Sie wahrscheinlich nur einen neuen Inhaltstyp vom Typ Knotenentität erstellen.
    • Wenn ja, dann weiter ...
  5. Sind Sie sicher, dass Sie den Node-Entity-Typ nicht einfach erweitern können und alle nützlichen Funktionen wie CRUD-Operationen neu erstellen möchten?
    • Wenn ja, erstellen Sie einen neuen benutzerdefinierten Entitätstyp.
    • Wenn nein, oder wenn Sie sich nicht sicher sind, möchten Sie wahrscheinlich einige Experten hinzuziehen, die Ihnen bei der Entscheidung helfen.

Anmerkungen:

  1. Dieser Entscheidungsbaum berücksichtigt weder Leistung noch Sicherheit. Ich bin nicht sicher, ob oder wann ein neuer benutzerdefinierter Inhaltsentitätstyp eine bessere Leistung erbringen und mehr oder weniger sicher sein würde als ein Knotenentitätstyp.
  2. Selbst wenn dieser Baum eine gute Antwort ist, wird er aufgrund von Aktualisierungen in Drupal Core- und Contrib-Modul-Releases wahrscheinlich nicht im Laufe der Zeit bleiben. StackExchange scheint nicht zu berücksichtigen, wie die "beste" Antwort ist heute ist vielleicht morgen nicht die beste Antwort.)
17
Jon Freed

Schlicht und einfach: Es ist nicht alles Inhalt. Die Liste des Inhalts kann sehr lang und verwirrend sein, wenn Sie nur Inhaltstypen verwenden. ( ContentEntityBase könnte auch von einer benutzerdefinierten Entität implementiert werden.

Wenn Sie einen Autor und einen veröffentlichten Status haben sollten Sie sich für einen Inhaltstyp entscheiden.


Andernfalls (vorausgesetzt, Sie sind Programmierer) sollten benutzerdefinierte Entitäten bevorzugt werden. Mit allen Schnittstellen kann viel einfach implementiert werden (wie revisionsfähig, feldfähig, Zugriffsbeschränkung usw.).

Meiner Ansicht nach ist dies nur eine klarere und nach hinten geordnete Architektur (und auch performanter).

Wenn man an die Wiederverwendbarkeit in mehreren Projekten denkt, muss man sich bemühen, die benutzerdefinierten Entitäten zum Platzen zu bringen. Es gibt auch raffinierte Helfer wie Drupal-Code-Generator . Um die benutzerdefinierte Codierung (oder Komplexität) auf einem niedrigen Niveau zu halten, sollten Sie die Verwendung von Inhaltstypen in Betracht ziehen, wenn Sie Folgendes möchten:

  • Um die 'Entität' (zumindest in D7) zu übersetzen, gäbe es auch eine Schnittstelle.
  • (offen für Vorschläge) ..
3
rémy

Es ist eine schwierige Frage, die meiner Meinung nach erst verstanden wird, wenn Sie sie zuvor implementiert haben. Aber wie gesagt: nicht alles ist roh, benutzerbezogener Inhalt.

In Drupal 7) gab es die Möglichkeit, benutzerdefinierte Entitäten zu erstellen, aber es könnte eine entmutigende Aufgabe sein, wenn Sie mit OOP an den Rändern rau waren. Es wurde zur Hälfte implementiert (oder zur Hälfte erledigt, wie auch immer Sie es taten Ich möchte es sagen), die dazu führen, dass Entitäten geschaffen werden, die nicht alle genau einheitlich sind und sich auf Ansätze geeinigt haben, mit gemischten prozeduralen und gemischten OOP.

In Drupal 8) wird die Idee viel mehr verwirklicht und es ist viel einfacher, mit einer benutzerdefinierten Entität zu arbeiten. Node selbst basiert auf ContentEntityBase sowie Blöcke, Benutzer, Dateien und Taxonomie.

Knoten sind speziell für veröffentlichte, sichtbare (oder autorisierte) Inhaltsdaten, die normalerweise als Inhalt fungieren (dh in einem Menü oder in der Sitemap oder XML-Sitemap oder RSS-Feeds usw.). Drupal wurde so konzipiert, dass Sie sich in jeden Schritt des Prozesses der Knotenoperationen einbinden und ihn ändern können, was unbeabsichtigte Konsequenzen haben kann, wenn Sie die falsche Mischung der bereitgestellten Module haben. Dies ist wahrscheinlich eine kontroverse Meinung, aber es hilft, sich von der Idee "Alles ist ein Knoten" zu trennen, um das Entitätskonzept mehr zu akzeptieren.

Ideale Inhalte, die großartige Inhaltstypen ergeben:

  • Artikel
  • Seite
  • Stellenausschreibung
  • Veranstaltung
  • Landing Page
  • Startseite

Der rote Faden für sie ist, dass sie ein Konzept für eine Art von Inhalt teilen. Es befindet sich normalerweise in einer beliebigen Anzahl von Workflow-Zuständen (veröffentlicht, beworben, klebrig, archiviert, vorgestellt usw. - wenn Sie benutzerdefinierte Veröffentlichungsoptionen verwenden), und eine große Anzahl von beitragenden Modulen interagiert direkt damit, wie z. B. Pathauto.

Nehmen wir jedoch an, Sie möchten Daten in Drupal) speichern, das intern, privat ist, andere Daten steuert oder Daten, die keine Integration außerhalb ihres Gültigkeitsbereichs zulassen sollten, sofern Sie dies nicht zulassen. Welche Art von Daten könnte dies sein Hier sind einige mögliche Typen:

  • Produkt (Drupal Commerce)
  • Werbebuchung (Drupal Commerce)
  • Suchserver (ApacheSolr/SearchAPI)
  • Kontakt (wie CRM-Lead)
  • Ticket (wie Support-Ticket)

Was macht diese so anders? Warum möchten Sie eine Entität für den Kontakt, anstatt das Benutzermodell zu verwenden? Sie könnten dort einige Argumente vorbringen, aber mein Beispiel wäre, dass Sie diese Daten als benutzerdefinierte Entität speichern, wenn Sie beispielsweise E-Mail-Adressen und -Namen sowie einige andere Metadaten aus einem Kontaktformular erfassen. Sie verhindern, dass die Benutzerliste mit Nicht-Kontoelementen verschmutzt wird, Sie reduzieren potenzielle Sicherheitsprobleme (was passiert, wenn ein Skript oder jemand diese Konten versehentlich als Administratoren aktualisiert oder eine Massenmail gesendet hat?), Sie führen eine interne Overhead-Verwaltung des tatsächlichen Benutzers durch Konten einfacher, und Sie segmentieren das, was Sie erfassen, in das, was es ist, ein spezielles Datenbit.

Von hier aus ist es weitgehend von den automatischeren Teilen des Drupal/Node-Systems getrennt, und Sie können die Aktionen und Erfahrungen anpassen. Sie bestimmen die Routen, den Zugriff und den CRUD-Workflow.

In dieser Denkweise ist es einfacher zu erkennen, warum der Ansatz so gemacht wird. Nehmen Sie das Beispiel für ein Support-Ticket - es handelt sich um eingehende Anfragen, aber nicht um veröffentlichte Daten, und es gibt wahrscheinlich einen sehr spezifischen Workflow, der einfacher einzurichten ist, als ihn von Teilen des Knotensystems zu trennen, an denen er nicht haften soll zu.

Ein weiteres Beispiel wären externe, importierte Daten. In den meisten Fällen sind diese Daten normalerweise nicht mit lokalen Drupal -Daten angereichert (auch wenn Sie dies als Einheit noch tun können). Es kann alles sein. Vielleicht sind es Rechnungen, vielleicht es sind Bücher, vielleicht zieht es Biermarken.

Daten wie diese sind normalerweise spezifisch und erfordern eine Kontrolle darüber, wofür der Knoten bestimmt ist. Das heißt nicht, dass Sie es nicht erweitern können, indem Sie ein Referenzfeld auf einem Knoten verwenden, um auf Ihre benutzerdefinierte Entität zu verweisen (so hat Drupal Commerce hat auf einer bestimmten Ebene funktioniert), um anzureichern Gleichzeitig isolieren und gewährleisten Sie die Kontrolle über Ihre Daten und die Benutzeroberfläche von fehlerhaftem Contrib-Code, der über das Design hinausgeht und Ihr Modell beeinträchtigt. Dies ist in D8 wahrscheinlich weniger problematisch als in D7, obwohl einige Haken bleiben.

Die richtige Architektur existiert jetzt, um die Trennung zu fördern. Nicht alles ist ein Knoten.

3
Kevin

Ein einfacher Ansatz zu diesem Thema müssen der Projektzweck, die Größe und die Geschäftsanforderungen berücksichtigt werden.

  1. How Der Standardinhaltstyp für Knotenentitäten wirkt sich auf die einfache und übersichtliche Erstellung des Projekts aus, die näher an der Architektur und den Datenflüssen liegt, die aus dem analytischen Denken von Projektdokumenten hervorgehen.

Ein wichtiger Hinweis Hier wurde die Entscheidung zum Erstellen eines neuen Entitätstyps normalerweise von Entwicklern oder technischen Leads getroffen, nicht von Site Buildern oder Projektbesitzern, die die Anwendung verwalten und sich nur auf das Geschäft konzentrieren.

  1. Drupal 8 hängt von einigen symfony2-Paketen ab und ist näher an Frameworks, einer Entwicklung, über die traditionelle CMS sprechen Drupal Mit diesen großen architektonischen Änderungen stelle ich mir vor, eine neue Entität zu erstellen Besser als viele Anpassungen und komplexe Konfigurationen über Inhaltstypen von Knotenentitäten vorzunehmen, um Drupal unter anderen Frameworks zu nutzen, da viele Leute den Weg nicht lieben Drupal) Konfiguration und verteilte Einstellungen, Sie können sich einigen Leuten stellen, die von WordPress] stammen und verwendet werden, um alles aus einer Form heraus zu konfigurieren, was sie beim Umgang mit dem Drupal admin) verärgert Instrumententafel.

  2. Drupal 9 plant, das Hook-System vollständig zu entfernen und durch Event Dispatcher zu ersetzen, was zu einem großen Bedarf an einer Admin-Schnittstelle führt, um eine neue Entität zu erstellen, da die vorhandene Funktionalität aus dem Code geändert wird viel schwieriger für Leute, die keine Entwickler sind und sehr wichtig sind, um diese Funktion hinzuzufügen.

Am Ende Ich sehe, dass neue Entitäten, die auf die Projektanforderungen zugeschnitten sind, eine höhere Leistung bieten als komplexe Inhaltstypen mit einer großen Anzahl von Feldern, da jetzt jedes Feld der Datenbank 2 Tabellen hinzufügt und seine Konfiguration laden muss auf jede Anfrage, insbesondere mit der erforderlichen schweren Geschäftslogik.

3
Mohammed Gomma