Hierarchische Gruppen

für die Liste aller Seiten

Entwickler und Administratoren

Diese Seite erklärt, warum es keine hierarchischen Gruppen gibt.

PMs Erklärung

Als Wikigruppen implementiert wurden, dachte ich eine Weile über die Implementierung hierarchischer Gruppen nach, entschied mich letztendlich dagegen aus mehreren Gründen:

Es scheint keine zusätzliche Power oder Flexibilität hinzuzufügen.
Es fügt Komplexität in Bezug auf Referenzen auf Seiten in anderen (Unter-) Gruppen hinzu.
Ich untersuchte andere Systeme, die hierarchische Gruppen implementieren und mochte die Komplikationen nicht, die sie anscheinend mit sich bringen.

Wenn man den ersten Punkt betrachtet und das gegebene Beispiel heranzieht, dann kann man statt Animal.Mammal.Canine.StBernard ebenso gut AnimalMammalCanine.StBernard schreiben und erhält grundsätzlich die gleichen Ergebnisse und Möglichkeiten. Oder, wenn wir wirklich Separatoren brauchen, erlauben wir vielleicht Bindestriche in Wiki-Gruppennamen und schreiben etwas wie Animal-Mammal-Canine.StBernard.

Ich widerspreche. Die Gruppe AnimalMammalCanine hat keine implizite Beziehung zur Gruppe Animal in der Weise wie Animal.Mammal.Canine es hat. --Profiles/EvanProdromou

Vom praktischen Standpunkt aus: Wie würde eine "implizite Beziehung" irgendetwas in Beziehung auf die Art und Weise ändern, in der Seiten gerendert oder interpretiert werden? --Pm?

PmWiki würde die Beziehung zwischen der Animal-Gruppe, der Animal.Mammal-Gruppe und der Animal.Mammal.Canine-Gruppe "kennen". Das wirkt sich auf verschiedene Funktionen aus: Gruppensuche (würde Untergruppen abdecken), Umbenennen (Verschieben einer Gruppe an eine anderen Stelle würde auch die Seiten der Untergruppen betreffen), Seitenlistenerzeugung (auch hier würden Untergruppen eingeschlossen werden - gut für die Erzeugung von WikiTrails, die mehrere Hierarchien überspannen).
Viele dieser Punkte könnten gut funktionieren, wenn man Jokerzeichen in den Gruppennamen in den verschiedenen Zusammenhängen erlaubte. Die Auswirkung dieses Ansatzes ist noch nicht gut untersucht.--JoachimDurchholz? May 24, 2006, at 05:00 PM

Die implizite Beziehung würde auch vererbte Befugnisse ermöglichen, so dass, wenn eine Passworteinschränkung auf die Animal-Gruppe gesetzt wird, diese Einschränkung automatisch hinuntergebrochen würde bis auf Animal.Mammal.Canine.StBernard. Um das mit dem AnimalMammalCanine.StBernard-Stil-Format zu behandeln, müsste jede Untergruppe separat geschützt werden. Anonymous, May 21, 2007

Vielleicht würde ein Design, wo man Gruppen abschneidet, einen besseren Unterschied machen? Z. B. Animal.MammalCanineStBernard vs. AnimalMammalCanine.StBernard oder vielleicht ein separates Wiki für verschiedene Hauptgruppen. – Ich habe noch nicht bei Farmen oder so etwas nachgesehen – Aber ich kann mir den Bedarf nach einer Untergruppe für ein Event vorstellen, z. B. Main.Events.Eventa (eventa hätte vielleicht 10 Seiten). Mir scheint, Events sollten ihre eigenen Wikis in einer Wikifarm haben? Ich sah irgendwo, dass sich Wikis auch Logins teilen können? Patrick, July 4, 2009

Es wäre schön, wenn Seiten in einer Hierarchie definiert werden könnten (ich würde eher sagen, klassifiziert), so dass kontextsensitive Menüs erzeugt werden könnten. Ein Grund für die Definition zusätzlicher Beziehungen könnte die Unterstützung zusätzlicher Menüs für Brot-Krumen-Navigation und verwandte Links sein, Alles automatisch erzeugt für jede Seite. --pacoit

Zu dem zweiten Punkt: Das Problem erscheint bei dem Versuch, zu entscheiden, was man mit einem Markup wie "Canine.StBernard" in der Gruppe "Animal.Mammal" machen soll, insbesondere, wenn es eine Top-Level-Gruppe namens "Canine" gibt. Wenn wir Group.WikiWord immer als absolut behandeln, gibt es keine wirklichen organisatorischen Vorteile durch die Hierarchien. Wenn wir relative Pfade erlauben, dann gibt es alle möglichen Sorten von Raum für Mehrdeutigkeiten, außer es werden noch mehr Markups hinzugefügt, um diese aufzulösen, und es ist möglich, dass jemand, der eine Seite in einer mittleren Untergruppe erzeugt, damit unbeabsichtigt das Ziel existierender Links verändert. Was es Alles schwieriger macht für naive Benutzer.

Es gibt da tatsächlich ein Problem. Hierarchische Dateisysteme lösen das, indem sie absolute Pfade durch die Syntax unterscheiden (z. B. in Unix durch voranstellen eines '/').
--JoachimDurchholz? May 24, 2006, at 05:32 PM

Eines der zentralen Probleme ist, dass es, wenn ein Name sich auf beides bezieht, eine Gruppe und eine Seite, zwei widerstreitende Institutionen gibt, was denn die "aktuelle Gruppe" dieser Seite ist. Es könnte die Seite selbst sein oder ihre Elternseite.
--JoachimDurchholz? May 25, 2006, at 03:27 PM

Da PmWiki nicht hierarchie-konform ist, kann ich es nicht auf unserer Site benutzen. Wir brauchen mindestens eine 3-stufige Hierarchie. Hierarchie in PmWiki ist ein technisches oder ein philosophisches Problem?
--Romiras (romiras@sources.ru)

Hallo, ich möchte herauskehren, dass Cookbook:Cluster eine sehr brauchbare Lösung dieses speziellen Problems ist. Es ist keine perfekte Lösung, weil es nicht so eng integriert ist, wie es eine Core-Lösung sein könnte, aber ich glaube, dies ist in diesem Augenblick die beste Lösung des Problems und sehr funktional.

In meinem Fall hatte ich eine schwierige Zeit beim Übersetzen in PmWikis Stil der inhaltlichen Trennung; Es ist nicht so sehr die Art wie ich arbeite und mich da hineinmanöverierte, während der Prozess meiner Meinung nach nicht gut arbeitete. ;)

Lassen Sie 's mich illustrieren und lassen Sie uns das gegebene Beispiel benutzen: Animal-Mammal-Canine.StBernard.

Aus meiner Sicht sind die Probleme mit eine flachen Hierarchie, so wie PmWiki die Wikigruppen behandelt, einfach, dass es keine Kohärenz zwischen Fake-Levels gibt. Wenn ich zum Beispiel den GroupHeader in Animal ändere, das wäre dann Animal.GroupHeader, würde ich erwarten, dass das in ihren Kindern Auswirkungen hat, etwa in Animal-Mammal/. Dies kann automatisch durch das Cluster-Rezept bewerkstelligt werden (ebenso wie ein Stil der Vereinfachung von Links zwischen Kindern und/oder Eltern). Ein ähnliches Versagen dieser Basismethode ist meiner Ansicht nach, dass ich erwarte, dass ich meinen Fokus leicht auf die Elterngruppe verschieben kann (das alte cd .. ;)). Meine Modifikation am Cluster-Rezept erleichtert das durch einen klickbaren Trail, der in der Seite eingefügt werden kann (d. h. im Groupheader in meiner persönlichen Benutzung).

Zusammengefasst: mit dem Cluster-Rezept kann man die Probleme mit dem Animal-Mammal-Canine.StBernard-Stil der Hierarchie bewältigen. Ich bevorzuge diese Methode vor PmWikis flacher Hierarchie und habe bis jetzt keine Probleme gehabt und kann nur Gutes sagen.

Meine persönlichen Überlegungen sind, dass etwas von dieser Natur wichtig genug ist für die Brauchbarkeit, um als optionaler CoreCandidat zu gelten wie creole markup es ist, allerdings arbeitet die Rezeptmethode gut solange wir alle von ihr wissen und natürlich kann sie dafür eingesetzt werden.

My best regards to you,

Feral? March 13, 2007, at 11:17 PM

Vielleicht nicht die richtige Plattform

Ich müsste zustimmen, dass für einige Anwendungen oder für einige von uns, die ein mentales Konstrukt hierarchischer Systeme haben, PmWiki damit Schwierigkeiten hat. Ich habe rauf und runter gesucht, um herauszufinden, wie Trails, Links und Gruppen funktionieren. Ich glaube, ich habe angenommen, ich könnte innerhalb von Gruppen gruppieren. Das Ergebnis war, dass Links und Seiten zu verschwinden schienen. Trails leiteten auf Orte, die keinen Sinn machten und Umbenennen einer Gruppe löste Verbindungen zu dem, was ich als Kinder ansah.

Als ich dies hier gelesen habe, sagte es mir, dass es Möglichkeiten gibt, meinen Denkprozess über Beziehungen zu ändern, aber ich glaube, ich bin zu alt und festgefahren in meinen Wegen, als dass ich all dies neu überdenken kann und die beste Lösung ist, ich finde eine andere Plattform. Das soll nicht heißen, dass die Entscheidung für diese Plattform nicht gut überlegt ist und für viele (oder vielleicht für die meisten) Menschen funktioniert.

Hat irgendeiner einen Vorschlag für eine Plattform, die eine gute Ersetzung wäre?

Geschichte

Dieses Topic wurde in der pmwiki-users mailing list über eine große Strecke von mehreren Anlässen während 2003 und 2004 diskutiert und der generelle Konsens scheint dies zu sein:

Der aktuelle Ein-Gruppen-Level-Mechanismus wird als der Beste (oder am wenigsten Schlechte) unter allen erreichbaren Alternativen angesehen.
Sowie eine gute Syntax und Semantik für hierarchische Gruppen gefunden wird, wollen wir 's haben. Aber wir wollen hier keine schlechte Lösung.

Die Software wurde so gestaltet, dass sie eventuell hierarchische Gruppen unterstützen könnte über ein Kochbuch-Rezept, wenn wir je die ausstehenden Angelegenheiten lösen.

Alternativen

Es gibt auch anderen Alternativen zum Gebrauch von Gruppenhierarchien, um Seiteninhalte zu organisieren — Seitenabfolge, Kategorien und Wikifarmen können oft die Angelegenheiten mit mehr Power und Flexibilität lösen als Wikigruppen das können.

Das Cookbook:SubgroupMarkup-Rezept fügt eine Ebene von Untergruppen zu der aktuellen Wikistruktur hinzu. Für viele Probleme mag das befriedigend sein. Es führt ein [[,subpage]]-Markup ein, um eine Unterseite zu der aktuellen Seite zu bezeichnen. Die Unterseiten zu einer bestimmten Seite formen eine Untergruppe der aktuellen Gruppe. [[,proposals]] und [[,discuss]] sind zum Beispiel Seiten in der PmWiki.HierarchicalGroups-Untergruppe der PmWiki-Gruppe.

Anregungen

Die Angelegenheiten wurden in der Mailingliste auf und ab diskutiert, Zusammenfassungen von Vorschlägen, konzeptuellen Hintergründen und andere Diskussionsergebnisse sind in der PmWiki:HierarchicalGroups-Proposals-Seite zu finden.

Category: PmWiki Design für die Liste aller Seiten

Übersetzung von PmWiki.HierarchicalGroups, Originalseite auf PmWikiDe.HierarchicalGroups — Backlinks

Zuletzt geändert:	PmWikiDe.HierarchicalGroups	am 23.12.2021
	PmWiki.HierarchicalGroups	am 23.12.2021