0012196: Anordnung Objektfelder

[SteffiS]

Ursprünglicher FR (von dehrich):

Wäre es denkbar, ähnlich wie in der Kundenverwaltung, den Feldern einen eigenen Bereich zuzuordnen? Das ganze könnte dann beispielsweise auch als Tabs angezeigt werden. Je Bereich, ein Tab (Unterhalb von Eigenschaften,...). Der Benefit für Redakteure wäre hier enorm, da sich die Daten so nochmals besser strukturieren lassen, gerade bei sehr großen Objektstrukturen.

___

Rückmeldung Lukas:

für Objekte wäre es tatsächlich am einfachsten, statt irgendwelcher Reitergeschichten einen Feldtyp Fold zuzufügen und den dann so umzusetzen, dass in einn Fold alle folgenden Felder bis zu einem etwaigen nächsten Foid eingepackt werden: dann kann man ganz oben die "ungepackten" Felder stehen haben und ab dem ersten Fold wird auf jeden Fall alles eingepackt.

wollte man es ermöglichen, auch nur in der Mitte einige Felder in ein Fold zu stecken, bräuchte es ein öffnendes und ein schließendes Fold-Feld:
=> das halte ich jedoch für völlig überflüssig...

will heißen: <we:fold> und einen simplen Feld-Typ Fold können wir gleich anerkennen. was komplexeres (für Objekte) müsste erst ins Forum

___

Mein Senf:

Finde den Fold ansatz von Lukas auch besser als die Reiter-Idee. Objektfelder nach jedem "Fold" werden gruppiert. Sollten vor dem "Fold" noch Felder sein bleiben diese "lose".
Zusätzlich fänd ich die Möglichkeit einer Betitelung der Gruppe nicht schlecht. Entweder integriert man das beim Feldtyp "Fold" oder macht sogar einen eigenen Feldtypen daraus. Dann kann mans auch ohne Klappfunktion strukturieren.
Wichtig wäre vielleicht noch dass man allgemein die Einstellung treffen kann, ob die "Falten" standardmäßig geöffnet oder geschlossen sind wenn man ein Objekt zur Bearbeitung aufruft.
Uuund nochmal weiter gesponnen könnte man jeder Gruppe vielleicht noch eine Farbe zuordnen.

[ThomasGoebe]

Bitte dabei bedenken, wie mit nicht ausgefüllten Pflichtfeldern umgegangen werden soll.

[SteffiS]

Aktuell gibt es ne Warnmeldung. Das schließt sich nicht aus? Oder meinst du weil nicht direkt ersichtlich sein könnte, wo sich das Pflichtfeld "versteckt"?

[ThomasGoebe]

Aktuell gibt es ne Warnmeldung. Das schließt sich nicht aus? Oder meinst du weil nicht direkt ersichtlich sein könnte, wo sich das Pflichtfeld "versteckt"?

letzteres. Gerade bei vielen Feldern sollte es dann kein Suchspiel werden, welcher Akkordion Eintrag ein fehlendes Pflichtfeld enthält. (Zumal irgendwann noch weitere logische Prüfungen auf Feldinhalte denkbar sein könnten, wie korrekte E-Mail Adressen etc.)

[blickfang]

zur Anordnung der Objektfelder gibt es von mir noch einen verwandeten FR viewtopic.php?t=42251

[SteffiS]

letzteres. Gerade bei vielen Feldern sollte es dann kein Suchspiel werden, welcher Akkordion Eintrag ein fehlendes Pflichtfeld enthält. (Zumal irgendwann noch weitere logische Prüfungen auf Feldinhalte denkbar sein könnten, wie korrekte E-Mail Adressen etc.)

Falls möglich könnte man ja den Akkordion-Kopf mit einem Hinweis-Symbol versehen. Ggfs. sogar den Alert mit einer entsprechenden Info versehen. Bin jetzt keine große Coderin, also verzeiht, wenn ich die Machbarkeit nicht immer einschätzen kann

[LOOK//one]

Wir mögen die Idee Nicht ausgefüllte Pflichtfelder könnten beim Speichern rot markiert und das zugehörige Accordeon aufgeklappt werden.

[ArminSchulz]

Finde die Idee mit fold nicht schlecht

zu den Pflichtfeldern:
das nicht gefüllte Feld wird ROT umrandet (oder was auch immer, und der umgebende Fold wird aufgeklappt...
ohne das Aufklappen blickt man sonst nicht durch

[SteffiS]

Ich könnte mir auch noch ein Warnsymbol auf dem jeweiligen einleitenden Fold vorstellen (In meinem Beispiel der, grüne, violette, orangene Balken). Wenn man gerade sowieso einige Folds geöffnet hat, fällt es ggfs nicht so auf, wenn sich Einer mit unausgefülltem Pflichtfeld zusätzlich öffnet. Und natürlich, wie gehabt, eine visuelle Hervorhebung wie aktuell auch, z.B. in Rot.

[blickfang]

In meinen Ansatz in der Bugbase habe ich zur Diskussion gestelt, ob die Verwaltung der Felder in der Klasse untereinander erolgen muss, oder das zur besseren Übersichtlichkeit auch in den Tree ausgelagert werden kann. Mit der Möglichkeit im Tree dann auch Panels/Verzeichnisse zu definieren, welche dann wiederum eine Grupe an Feldern haben könnte, würde man maximale Freiheit in der Anordnung der Felder erreichen. Ich finde eine Ebene als Gruppierung hier zu kurz gedacht. Farben würde ich optional sehen, aber nicht vom System vorgeben. Ich hänge hier mal noch das Beispiel aus dem anderen CMS rein, wie das meiner Meinung nach in der Verwaltung der Felder sehr flexibel gelöst ist.

[mokraemer]

@Timo: ich vermute mal die Abbildung ist Leuten die das CMS nicht kennen eher fremd und auch nicht selbsterklärend. Ich finde das hier etwas verwirrend - mag sein das es ein guter Ansatz ist, aber er erschließt sich mir nicht.

Eines würde ich am Rande auch zu bedenken geben: ein Fold wäre schnell eingebaut. Eine Lösung wie hier gezeigt, erfordert mindestens eine Framework, was die Konfiguration erledigt, und dann die Ausgabefunktion so umbauen bis es dieser Konfig auch entspricht. Da sollte man dann klären, ob das im Verhältnis steht zu dem wo und wie es eingesetzt wird.
Bei dem Einbauen von Frameworks sind wir generell konservativ. Denn anders, als im Frontend, wo man eine Webseite nach 3-4 Jahren neu baut, lebt WE seit ~2000. In der Zeit sind viele (große) FW gekommen und gegangen oder eingeschlafen. Keines davon ist kompatibel und bspw. solche Sonderlösungen, wie die hier im Bild gezeigte, sind nicht schnell nachzubauen, wenn das FW dazu stirbt.
Auch das monitoren von Lücken, Fehlern etc. schießt durch die Decke, wenn wir viele davon einsetzen; daher versuchen wir uns weiter auf die Basics zu beschränken - auch wenn der eine oder andere Frontendentwickler das als "unsexy" erachet. Wenn wir das ändern woll(t)en, dann brauchen wir auch mehr (Frontend-) Entwickler, die sich um diesen Kram kümmern uns beim Wegfall gleichwertigen Ersatz bauen können.

[blickfang]

ich versuche nochmals auszuführen, falls das Bild nicht selbsterklärend ist:

Objektfelder werden nicht mehr im Bearbeiten Fenster verwaltet, sondern im Dokument-Tree dargestellt. Das Bild zeigt also den Tree. Klickt man auf einen Eintrag im Tree, wird dieser in unseren Bearbeiten Tab angezeigt. Sprich an dieser Stelle das Objektfeld oder eben ein Konfigurationsfeld für die Darstellung/Gruppierung.

Warum wir dafür zwingend ein Framework benötigen, erschließt sich mir hingegen nicht direkt. Für die Anzeige in Redakteursansicht könnte man über alle Felder iterieren und je nach Feldtyp dann eine Gruppe/Fold oder nur ein Feld hinmalen. Die Erweiterung um ein Panel würde letztlich auch nur definieren, wo ein Feld oder eine Gruppe/Fold steht.

Die Diskussion um FWs ist an dieser Stelle nicht Kern der Diskussion, aber ich sehe durchaus Vorteile. Wichtigste Vorteile sehe ich darin, dass es bereits eine Dokumentation gibt und sich mit einem verbreiteten FW direkt mehrere Entwickler auskennen. Die Einstiegshürde in eine Community-Lösung ist als Entwickler wesentlich geringer und die Lernkurve viel flacher. Wenn bewährte und bekannte Tools eingesetzt werden, können Aufgaben somit schneller und einfacher auf mehrere Köpfe verteilt werden.

[ThomasGoebe]

Also das gepostete Bild finde ich sehr unübersichtlich. Da ist mir das jetzige Bearbeiten der Klassen sogar lieber.

[mokraemer]

hmm. gut, man kann natürlich die Felder einer Klasse links im Tree ebenfalls anlegen und damit mit der Klasse aufklappen - der Tree hat hier ja nur eine Ebene - das ist durchaus machbar. Damit könnte man zumindest mal in der Ansicht an die Stelle in der Klasse springen (wenn das geht)

Ich dachte nur hier geht es mehr um die Bearbeitung der Objekte, und weniger um die Klasse

[lukasimhof]

Ich halte Timos Vorschlag generell mal für sehr aufwändig: und da ich sponntan nicht davon ausgehe, dass so sehr große Mengen an Objekt-Feldern der Normalfall sind (und von der Datenorganisation her auch nicht wirklich sein sollten), sehe ich die Idee auch eher als unverhätnismäßig an (wir haben bei Astendo leider auch eine solche Mega-Klasse, aber die weitere 99 Klassen sind bereits deutlich überschaubarer...).

Allerdings denke ich gerade an die sehr einfache Art, wie man seit 9.0.x vom Sidebar-Dokument aus Ankersprünge ins aktuell geöffnete Dokument machen kann: was, wenn man auch der Klasse ein Sidebardokument zuordnen und Sprünge zu den einzelnen Feldern anbieten könnte? Dann ließe sich auf dem Sidebardok auch recht einfach jeder beliebig maßgescheiderte Tree ausgeben (und wenn jemad dafür eine schöne Vorlage mit schönem FW-JS hat, kann er diese auch gerne über die Communitiy dann teilen...)...
=> kommmt noch dazu, dass man einen solche Sidebar-Tree unverändert für die Klasse wie die zugehörigen Objekte nutzen könnte.