Node-System für eigenes Modul ?

Liest sich gerade etwas wild, drum hake ich mal nach:

Du möchstest für deine Gallerie ein Modul schreiben, dass im System einen / mehrere eigenen Node-Typen (abseits von CCK) bereitstellt?

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Sehe gerade das ich sehr abgehackt erklärt habe.

Ausgangspunkt ist der das ich eine ganz spezielle Gallery für Bilder und Videos brauche.
Nach extremen Tests mit Gallery2 usw. bin ich soweit das ich eine selber schreibe !!!

Warum ich nun zu jedem "Item" ein Node erstellen will ist der Grund das ich Comments und Voting API wie bestehend nutzen möchte. Im Prinzip kann ich alles über mein Modul in eigenen Tables machen.

Ganz gerade heraus: Der einzige Grund warum ich mit Nodes arbeiten will ist die bestehende integration von Comments und der Voting API (fivestar).

-------

Ich zweifle aber schon alleine aus dem Grund das es geplanter maßen eine sehr große Seite werden wird und ich damit pro Item gleich eine Datenmenge von 2 Table entries habe!

Was meint ihr ?
Lieber die gewünschten Funktionen selber integrieren oder auf Nodes setzen ?

MfG

Uhu

.. einen eigenen Node-Type anzulegen oder diesen selber zu programmieren. Der Vorteil eines eigenen Node-Types liegt klar auf der Hand - er macht was du willst.

Wo ist das Problem? Hier ist eine Aufstellung der zu integrierenden Funktionen:
_node_info()
Gibt "Grudeinstellungen" des eigenen Nodes bekannt.
_menu($may_chache)
Einhängen des Nodes in das Menü.
_perm()
Einstellungen für die Erteilung von (Benutzer-)Rechten. Hier werden die unterschiedlichen Bearbeitungsformen definiert, z. B. 'edit own nodetype', 'view nodetype'.
_access($op, $node)
Rückgabe der Benutzerrechte. Man kann hier sehr genau steuern wer was machen kann und darf.
_form($node)
Definition der eigenen Formularfelder zu Nodeerfassung / -bearbeitung.
_validate($node)
Validierung der Daten aus den zusätzlichen Formularfeldern
_insert($node)
Speicherung der zusätzlichen Daten.
_update($node)
Speicherung nach der Bearbeitung.
_delete(&$node)
Löschfunktion des Node's.
_load($node)
Holt die zusätzlichen Daten des Node's, z. B. für Updates.
_view($node, $teaser = FALSE, $page = FALSE)
Hinzufügen der Daten zu dem Node für die Anzeige im Browser.
theme_xx()
Möglichkeit die Ausgabe mit eigenen Formatierungen zu versehen.

Lass dich nicht von den Leuten abschrecken, so schlimm ist das nicht. Teile mal das Ergebnis mit

Gruß

UwBach

Hallo

Vielen Dank für die Antworten.
Was Programmierung angeht bin ich ein sehr erfahrener User.
Auch wenn ich in Drupal relativ frisch bin mache ich mit um die Umsetzung keine Sorgen...
Es geht mir mehr darum ob es sinn macht zu den von meinem Modul gestorten Daten noch je ein Node zu erstellen nur um eben die bestehenden Funktionen um einen Node herum gleich nutzen zu können.

Es geht wirklich nur um den Nutzen der bestehenden Module.
Ansonsten gibt es da nichts was ich nicht mit mehr Aufwand selber schreiben könnte !

MfG

Uhu

Es macht definitiv Sinn auf das Nodesystem aufzusetzen:
// http://drupal.org/node/132845: Hier wird beschrieben wie man sich so ein Modul schreibt
1. man kann den Inhaltstyp erweitern mit CCK, und muss so nur Teile selber programmieren
2. es kommt automatisch ein Revision-System hinzu
3. man kann die Daten in weiteren Modulen verwenden lassen, z.B. token|pathauto oder Views
-> Es spricht nichts dagegen, sich ein Nodemodule zu schreiben
--------------
Blog www.freeblogger.org: Deutscher IRC-Channel: irc.freenode.net #drupal.de ... Jabber-me: dwehner@im.calug.deXING

Uneingeschränkte Zustimmung, mit einem eigenen Node nutzt man alle Vorteile die Drupal bietet und kann jedes Modul mit auf das eigene Node aufsetzen.

Das trifft nur auf die Standard-Daten eines Node zu. Alles was zusätzlich gemacht wird muss auch selber behandelt werden; sprich möchte man ein Revisionssystem das auch deine eigenen Daten einschließt muss man es selber programmieren. Sonst wundert man sich später gewaltig.

Das trifft nur auf die Standard-Daten eines Node zu. Alles was zusätzlich gemacht wird muss auch selber behandelt werden; sprich möchte man ein Revisionssystem das auch deine eigenen Daten einschließt muss man es selber programmieren. Sonst wundert man sich später gewaltig.
klar, aber man muss eigentlich nur eine vid hinzufügen, und die aus dem Nodeobjekt übernehmen, fertig.
--------------
Blog www.freeblogger.org: Deutscher IRC-Channel: irc.freenode.net #drupal.de ... Jabber-me: dwehner@im.calug.deXING

Ich bin grade dabei das mal aufzuschreiben, ist noch nicht fertig - aber schau mal hier rein.

Ich arbeite hauptsächlich an der Integration von Legacy-Systemen, d. h. das ich jede Menge Daten habe die nicht in einem Standard-Node darstellbar sind. Erweiterte Node-Typen bieten hier eine hervorragende Möglichkeit solche Daten in Drupal darzustellen. Und für mich wichtig, ich kann die Daten aus jeder anderen Datenbank holen bzw. speichern.

Dabei ist es ebend nicht damit getan eine vid zu übernehmen. Leider habe ich keine anständige Doku gefunden, die solche Möglichkeiten beschreibt. Die beste Beschreibung ist noch in "Pro Drupal Development".

Gruß

UwBach

Hi

Wo ist dabei der Unterschied zu meiner Idee ?
Nochmal eine kurze Erklärung:

Ich store in einem DB.Table meine Items.
Bei einem ItemAdd oder ItemEdit werden die anfallenden Daten in die jeweiligen Tables, also meinen oder den "Node Table" geschrieben. Mein Table "Item" enthält dazu dann ein Feld "nid" welches immer zum zugehörigen Node referiert.

Geht es an die Ausgabe der Daten in Listen oder Detailansichten gebe ich ein komplettes Objekt an die für die Ausgabe zuständige Instanz.

Gruß

Uhu

Dafür werden aber auch Funktionen wie Benutzerrechte, Zugriffskontrollen, usw. benötigt. Das sind Standard-Funktionen eines Nodes bzw. setzen viele Module auf die Funktionen eines Nodes auf.

Programmierst du eigene Funktionen musst die gesamten Standards selber berücksichtigen, was du nicht berücksichtigst gibt es nicht. Erweiterst du Nodes, und das ist fast beliebig möglich, bleiben dir die Grundfunktionalitäten vollständig erhalten. Es sei denn du überschreibst die Funktion explizit. Sieh die Nodes eher als abstrakte Klasse an, nimm was du brauchst und wie du es brauchst, den Rest ...

Gruß

UwBach