Tabelle vs Content_type

Reine Konfigurationsdaten werden üblicherweise mit einem eindeutigen Namen in der variable-Tabelle gespeichert. mit get_variable und set_variable werden die Werte gesetzt oder gelesen. In der .install-Datei des Moduls werden in der Regel die Variablen angelegt und Defaultwerte eingetragen. Dann sollte dort auch eine uninstall-Funktion existieren, die diese Variablen bei uninstall aus der Tabelle löscht.

Ich denke, das kann man nur schwer aus der Ferne sagen, wenn man die genauen Struktur für die Config-Daten nicht kennt.
Und es kommt natürlich auch drauf an, wer die Daten wie oft ändern soll.

Ich habe für ein Webseite kürzlich komplexe Filter-Configurationen in einer Taxonomie abgebildet.
D.h. es gibt versch. Felder, wo versch. Daten hinterlegt sind und je nach Art dieser Daten wird das Filter-Formular so oder anders aufgebaut.

Keine Ahnung, ob das Deinen Fall in etwa trifft.
Man hätte auch einen Content-Type machen können.
Wichtig war, daß die Kondigurationsdaten über die Oberfläche zu pflegen sein sollen, damit man nicht bei jeder kleinen Änderung (Filter schnell mal ausblenden) in den Code fassen muß.
Notfalls (aber besser nicht ;-)) kann das auch der Kunde nach entsprechender Schulung machen.

Eine eigene Datenbank-Tabelle würde ich eher nicht machen, sondern in Drupal-Logik einbinden.

Hier sollen Daten von einem extrenen Dienst abgefragt werden.
Diese Dienstzugänge ( es können mehrere sein) müssen irgendwo gepflegt werden.
Deshalb war mein Gedanke zunächst, content_types anzulegen, auf die nur Dienstadministratoren zugreifen können.

Andererseits muss eine Funktion, die über cron aufgerufen wird, diese Daten auslesen und verarbeiten (ja ich habe beschlossen, es über cron zu machen).

Es handlet sich um eine Struktur:

Dienst{'Aufruf':'https://.....', 'Username':'username', 'Password':'dienstpasswort'}

Davon kann es mehrere geben.

Hi Ronald,

wenn Du eine eigene Tabelle anlegen möchtest welche Du in Drupal einbinden möchtest,
solltest Du über die Entity API gehen.
Schau Dir den EntityController an damit sollte es gehen.

MfG

Robert

@Robert, was wäre indem Fall der Vorteil vom EntityController gegenüber einer Node-Entity?

Das ist die Diskussion, die ich wollte.
Dann kann ich sehen, was ich nachher mache.

Im Moment spricht noch vieles für den speziellen Node_Type für die Config-Einträge.

Ich möchte allerdings im Verarbeitungsloop gerne die betreffenden Records als Array haben, so dass ich sie einfach durchlaufen kann.

Das bekomme ich wahrscheinlich nur mit entity_field_query hin.

Ich tappe bei der Drupalstruktur noch ein wenig im Nebel, lerne aber gerade, obwohl dies nur ein Kleinprojekt ist, immens viel.

Hi @Montviso

node_entity vs entity_controller:
Bin mir da nicht ganz sicher aber wenn ich mich nicht irre,
kannst Du mit dem EntityController den Index deiner eigenen Tabelle verwenden.
Mit node_entity bist Du an den Index eines Nodes gebunden.

@Ronald
es kommt auf das Daten Model an, welches Du einbinden möchtest.
Bei nur einer Tabelle kannst Du auch über node_entity gehen.
Solltest Du eine komplette DB einbinden wollen mit eigenen Indexen und Referenzen,
ist der EntityController die bessere Wahl.

Grüsse

ich habe nur 3 bis 5 Records einfacher Struktur.