Taxonomiefrage: Node mit Taxonomie und Unter-Taxonomie versehen.

Ich frage mich, wieso Du das mit Taxonomien machen willst. Taxonomien dienen der Klassifizierung von Themenfeldern. Intuitiv würde ich für Kunde und Projekt eher einen eigenen Inhaltstyp anlegen und die zugehörigen Aufgaben per Entity Reference zuordnen. Aufgaben nach Kunden und Projekten auszugeben ist dann mit Views kein Problem.

Die Taxonomien würden es mir ermöglichen ein Kunde und ein Projekt "on the fly" zu erstellen. Ansonsten müsste ich ja vorher 2 Nodes anlegen und kann dann erst (auf der dritten Ebene) eine Aufgabe anlegen. Wäre umständlicher.

Und ich dachte diese Hierarchie von Kunde->Projekt->Aufgabe müsste sich auch über Taxonomien lösen lassen. Dann Taxonomien sind doch auch irgendwie nur Nodes (oder sagt man Entities)?

Danke und Grüße!

Mal unabhängig von der Frage, ob Tax. hier geeignet ist (ich würde sie vermutlich hier auch nicht verwenden, aber da müßte man die Datenstruktur und Ziele genauer kennen), kann man meines Wissens mit Autovervollständigung keine Unter-Taxonomien anlegen.
Du kannst nur nach dem Anlegen in die Tax. gehen und dort mit der Maus verschieben.
Wenn es allerdings mal mehrere Seiten werden, dann wird auch das mühsam.

Ich finde das mit dem Anlegen via Autocomplete nicht so toll, weil jeder Verschreiber dazu führt, daß ein neuer Eintrag gemacht wird, weil der alte nicht gefunden wird.
Später hast Du dann Helmut Meier und Meier, Helmut und Dr. Maier obwohl es der gleiche Kunde ist.
Natürlich wenn nur eine Person am System arbeitet, die nieeee so einen Fehler macht, dann mag es gehen...;-)

entity_references an.

Das ist wahrscheinlich eher dein Weg, auch wenn es technisch so ähnlich wie Taxonomies arbeitet, hast du mehr Möglichkeiten.

Schließlich haben Kunden eine andere Struktur wie Projekte.

Hast du dir ERPAL angesehen?

Dort ist vielleicht schon alles gelöst, was du hier neu erfinden möchtest?

Nein, Taxonomien bzw. Terme sind eben gerade keine Nodes, sondern Entities. Und das hat weitreichende Konsequenzen für die weitere Architektur. Bspw. kann ich für Content Types recht flexibel View Modes definieren und die Darstellung des Inhalts (also der einzelnen Nodes) flexibel an den Kontext anpassen. Ich kann für Content Types und auch für einzelne Nodes recht umfangreiche Berechtigungssysteme aufbauen und dabei die Berechtigung z.B. auch nach den zugewiesenen Termen steuern. Ob das in gleichem Umfang auch für taxonomische Vokabulare möglich ist - keine Ahnung. Oder nehmen wir das Thema Versionierung: für Content Types kein Thema, auf Entity-Ebene wüsste ich jetzt nicht, wie das funktionieren könnte.

Du solltest halt aufpassen, dass Du Dir mit Deiner Architekturentscheidung keine Dinge verbaust, die Du später noch brauchen könntest. Taxonomien sind für das, was Du damit abbilden willst, erst mal nicht gemacht. Ob das trotzdem Sinn machen könnte, lässt sich ohne tiefere Kenntnisse der Anforderungen nicht sagen.

Vielen Dank für die vielen Antworten!!!

Vielleicht muss ich noch mal etwas genauer beschreiben, was ich vor habe. Dann wird vielleicht auch klar, warum ich Taxonomien nutzen wollte.

Meine Idee ist die Nodes "Tätigkeiten" mittels Views nach Kunden und Projekte gesammelt auszugeben.
Dabei soll das so einfach wie möglich funktionieren ohne dass zuvor ein spezielles View für jeden Kunden oder übergeordnete Seiten etc. erstellt werden müssen.
Idealerweise soll dann unter "www.domain.de/kunde/projekt/" eine Liste aller Tätigkeiten (Bilder, Texte, Downloads) zu sehen sein.

Vielleicht bin ich ja auch ganz auf dem Holzweg und sollte das besser einfach über eine Menüstruktur machen oder so.
Was meint Ihr?

und überlege dir später die Datenstruktur nochmals neu.

Achtung, für die ganze Sequenz wirst du voraussichtlich 5 Tage brauchen.

http://nodeone.se/sv/node/20

Vielen Dank für den Tipp und den Link (der mir nicht ganz neu ist).

Kannst du ganz kurz vorwegnehmen, inwiefern ich diese Datenstruktur in 5 Tagen ändern werde ;-)
Eigentlich dachte ich, dass diese Anforderung ganz easy imzusetzen ist. Ist ja eigentlich wirklich nix dolles. Oder seh ich das falsch?

Mit Views kenn ich mich einigermaßen aus, so dass ich annehme (bzw. angenommen hatte), dass dies nicht das größte Probem wird ...

Vielen Dank und Güße.

Wenn du Taxonomies, Views und Entity Relations verstanden hast, wirst du dein Datenmodell so entwickeln, dass es das tut, was du dir wünschst.

Entwickle erst ein Datenmodell, führe die Normalisierung durch, und überlege dir dann die passende Technologie.

Eine andere Reihenfolge schafft nur mehr Probleme, als sie löst.

Was meinst Du denn genau mit Unter-Taxonomien? Ist ein Projekt vielleicht einem Kunden zugeordnet oder wie? Das kannst Du nicht so ohne weiteres aus dem Node-Formular heraus machen. Da würdest Du an eine Anpassung nicht vorbeikommen - ginge sicher auch, aber ohne Programmierkenntnisse nicht.

Du kannst ein Vokabular nehmen und statt vorgegebene Terms einfach ein offenes Feld zum Eingeben neuer Terms und mit Autoloading bestehender Terms anbieten, aber dann landen die Terms eben alle in einem großen Topf ohne jede Beziehung zueinander.Zudem: wenn Du zwei getrennte Vokabulare erstellst ("Kunden" und "Projekte") kannst Du zwischen den Terms aus diesen verschiedenen Vokabularen auch keine Beziehung herstellen.

Ich verstehe auch nicht ganz, wieso Du das alles aus dem Formular für Aufgaben heraus machen willst. Es klingt für mich nicht logisch (so rein organisatorisch), Aufgaben zu erstellen, bevor es ein Projekt dafür gibt - und ein Projekt zu erstellen, bevor ein Kunde angelegt ist. Für mich klingt es auch plausibler, Kunden und Projekte vorher als Nodes anzulegen und mit Entity Reference zu arbeiten. Es gibt auch Module, die es ermöglichen, die zu referenzierende Entity im Formular zu erstellen, vielleicht hilft das :https://www.drupal.org/project/noderefcreate

Mal an alle zum Thema Entities:

• Nodes sind auch Entites, nicht nur Terms
• Man kann auch bei Terms mit Revisionen arbeiten, die benutzen ja die gleichen Felder
• Ergo: streng genommen gibt es seit Drupal7 keinen nennenswerten Unterschied mehr zwischen Term und Nodes. Wenn man wollte, könnte man auch Terms wie Nodes verwenden und andersherum