Seite löschen (WebClient/ContentCreator) // Delete page (WebClient/ContentCreator)

Das Löschen einer Seite gehört aktuell nicht zu den Basisfunktionen des WebClients/ContentCreators und kann/muss aktuell nur über ein (projektspezifisches) Skript oder Lösch-Workflow bereitgestellt werden.

Problem:

Workflows werden in vielen Projekten gar nicht, spät oder erst in einer zweiten oder noch späteren Projektphase entwickelt und bereitgestellt. Dies führt dazu, dass Redakteure im WebClient/ContentCreator nicht mal selbsterstellte Seiten löschen können, selbst wenn sie dafür (im JavaClient/SiteArchitect) berechtigt sind. Zudem sind die im Projektkontext individuell und immer neu entwickelten Lösch-Skripte- bzw. Workflows erfahrungsgemäß relativ fehleranfällig und garantieren weder die Integrität der zu löschenden Objekte (Seiten/multiple Seitenreferenzen etc.) noch geben sie geeignete Hilfestellung bei der Auffindung & Auflösung von Abhängigkeiten (Medien, Mehrfachreferenzierungen, interne Verlinkung), welche eine Löschung verhindern.

Wunsch:

Da das Löschen von Content/Seiten eine absolute Basisfunktionalität darstellt, sollte dies in allen Client-Varianten standardisiert und zuverlässig funktionieren und von allen Redakteurs-Zielgruppen (Gelegenheits-/Poweruser) „Out oft he Box“ durchgeführt werden können, ohne dass Individualentwicklung nötig ist. Dies ist besonders wünschenswert, da das Löschen von Seiten durch die vielen möglichen Abhängigkeiten und Vorbedingungen  technisch nicht trivial ist.

Lösungsansatz/Vorschlag:

Der Löschversuch einer Seite sollte dem Redakteur alle Abhängigkeiten anzeigen, die ggf. das Löschen verhindern. Dabei wäre eine Liste/Referenzgraph a la „Abhängigkeiten anzeigen“ im JavaClient/SiteArchitect wünschenswert. Ein Klick auf eine das Löschen verhindernde Abhängigkeit springt direkt zum Medium oder der Seite und hebt ggf. sogar den Link auf der Seite (durch Abdunkeln des Rests) hervor (Erfahrungsgemäß ist – bei Seiten mit viel Content – das Auffinden von abhängigen Links auf der das Löschen verhindernden Seite nicht ganz einfach bzw. zeitaufwändig. Hier könnte – ähnlich wie bei der Hervorhebung von Änderungen auf der Seite durch Abdunklung der Umgebung – im WebClient sogar höhere Usability erreicht werden, als dies aktuell im JavaClient/SiteArchitect der Fall ist)!?

Besondere Aufmerksamkeit sollte bei der Implementierung der Basisfunktion Löschen dem Thema „Löschen mit Abhängigkeiten“ geschenkt werden. Ist eine Seite z.B. mehrfach in die Struktur eingebunden wäre ein Auswahldialog hilfreich/erforderlich, in dem (z.B. per Checkbox) die mit der Seite mitzulöschenden Seitenreferenzen ausgewählt werden können. Schön wäre hier jew. eine Anzeige, ob der löschende Redakteur das Recht hat, das Objekt zu löschen. Bei Abhängigkeiten über mehrere Ebenen (z.B. zu löschende Seitenreferenz ist zusätzlich von einer anderen Seite intern verlinkt, oder Medium auf Seite wird auch von anderer Seite eingebunden) wäre ein Löschen mit Abhängigkeiten unter Auflistung aller dann mitgelöschten Objekte genial.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

English version: not translated yet.

2 Comments
Andreas-Knoor
Crownpeak Employee
Crownpeak Employee

Unserer Erfahrung nach ist das Löschen von Objekten im Detail häufig projektspezifisch, insbesondere wenn es darum geht was "mit gelöscht" werden soll und welche Abhängigkeiten ein Löschen verhindern.

Trotzdem gibt es natürlich den Wunsch nach einer Lösung, die nicht immer (sofort) eine Programmierung mit projektspezifischen Anpassung erfordert.

Aus diesem Grund wurden "Standard-Workflows" entwickelt, die die üblichen 80% Grundfunktionalität zur Verfügung stellen, und zwar sowohl für das Löschen als auch für das Freigeben von Inhalten.

Diese sog. Basis-Workflows können beim Helpdesk angefordert werden.

Der Source-Code mit den Lösch- und Freigabelogik ist frei verfügbar und kann bei Bedarf im Projekt angepasst werden.

template_dev75
e-Spirit employee

Hallo und Danke für die Antwort.

Mir ist/war die Existenz der Basis-Workflows beim Verfassen des FRs bekannt. Meine Idee zielte daher auch mehr darauf ab, das „administrative“ Löschen, das im JavaClient ja selbstverständlich auch „out oft the box“ möglich ist, auch im WebClient komfortabel bereitzustellen, sodass sich die Basisfunktionalitäten des Java- und WebClients weiter anpassen…

So oder so – Wäre es dann nicht eine gute Idee, im ersten Schritt Mithras standardmäßig mit diesen Basis-Workflows auszuliefern, sodass das Löschen im WebClient (zumindest per Workflow) getestet/demonstriert werden kann? Das wäre toll und für mich als Trainer/Coach ein guter Anfang! Dann könnte man im Anschluss immer noch darüber diskutieren, ob/in welchem Maße die über die Basisworkflows bereitgestellte (Lösch-)Funktionalität als erweiterte Basisfunktionalität ins Produkt einfließen sollte oder nicht. Danke!