Spezielles Administrationstemplate

Ein CMSimple Support Forum für deutsch sprechende Nutzer und Entwickler
frase
Posts: 5085
Joined: Thu Apr 21, 2016 6:32 am
Location: Saxony
Contact:

Re: Spezielles Administrationstemplate

Post by frase » Fri Nov 24, 2017 11:09 am

lck wrote:Ich meinte eigentlich, dass bei ausgeschalteten Contenteditor auch das Select-Menü von Nutzen wäre, bei manchen Templates bestimmt. Weniger Kickerei. Aber das wäre wieder etwas für Holger, eine Option hinzuzufügen "Select-Menü immer anzeigen",
Ah, ja. Gute Idee.
Nachteil:
Das Verschiebe-Dingsbums braucht jQuery-UI. Und Bei Toch-Displays funktioniert es (momentan noch) nicht. Da müsste noch ein JQuery-Plugin nachgeleden werden. Das wird dann schon ganz schön viel - im Admin-Modus vielleicht nicht so schlimm ???

lck
Posts: 2963
Joined: Wed Mar 23, 2011 11:43 am
Contact:

Re: Spezielles Administrationstemplate

Post by lck » Fri Nov 24, 2017 12:29 pm

frase wrote:Das Verschiebe-Dingsbums braucht jQuery-UI. Und Bei Toch-Displays funktioniert es (momentan noch) nicht. Da müsste noch ein JQuery-Plugin nachgeleden werden. Das wird dann schon ganz schön viel - im Admin-Modus vielleicht nicht so schlimm ???
Glaube ich auch, was meint Christoph dazu? Es ginge evtl. auch ohne jQuery-UI, Beispiel.
„Bevor du den Pfeil der Wahrheit abschießt, tauche die Spitze in Honig!“   👉 Ludwig's XH-Templates for MultiPage & OnePage

frase
Posts: 5085
Joined: Thu Apr 21, 2016 6:32 am
Location: Saxony
Contact:

Re: Spezielles Administrationstemplate

Post by frase » Fri Nov 24, 2017 12:40 pm

Hm, das Beispiel müsst noch gestyled werden und hat Nachteile.
Es kann über Body hinausgeschoben werden und "snapt" nicht.
Ich denke aber, dass ein jQ-Plugin mehr oder weniger im Adminmodus wirklich nicht so eine große Rolle spielt.

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Spezielles Administrationstemplate

Post by cmb » Fri Nov 24, 2017 1:47 pm

lck wrote:[Glaube ich auch, was meint Christoph dazu? Es ginge evtl. auch ohne jQuery-UI, Beispiel.
http://youmightnotneedjquery.com/; hier konkret viewtopic.php?f=29&t=12752&p=60110#p60101.
Christoph M. Becker – Plugins for CMSimple_XH

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Spezielles Administrationstemplate

Post by cmb » Fri Nov 24, 2017 11:14 pm

frase wrote:Also eines steht fest: CMSimple_XH muss irgendwann eine modernere "Bedienoberfläche" bekommen.
Ich würde sagen, dass die Bedienoberfläche von CMSimple_XH kontinuierlich angepasst werden muss – was heute modern ist, ist morgen schon wieder veraltet. :)
frase wrote:Allerdings müssten dazu auch bestimmte Regeln (für die Programmierer) festgelegt werden.
Im Core müssten Buttons, Listen ... und alles mögliche andere eben mit eindeutigen Klassen oder IDs versehen werden, damit sie "style-technisch" angesprochen werden können. (Auch mit einem speziellen Admin-Template kann nicht unterschieden werden, ob es sich um eine Pagemanager-Liste handelt, oder um eine normale Text-Liste, wenn nur <ul> ohne Klasse oder ID definiert wurde.)

Z.B.:
xhButton, xhUL, xhOl, ...
Oder andere Schreibweise:
xh_button, xh_uL, xh_ol, ...
Hm, diese Feinheiten erscheinen mir überflüssig bzw. nicht wirklich passend. Ich denke, es sollte genügen (und sehr viel Flexibilität ergeben), wenn Plugins ihre Ausgabe in ein <div class="…"> einschließen (später statt <div> eben ein passendes HTML5 Strukturierungselement), und sehr vorsichtig sind, was Listen (und vielleicht auch ein paar andere Elemente) angeht. Ich selbst fand es früher ganz super alles mögliche als <ul> auszuzeichnen (ist oder war zumindest vor ein paar Jahren allgemein sehr beliebt); mittlerweile halte ich das für fraglich, weil es eben semantisch keinen Mehrwert bietet – sonst sollte man vielleicht mehrere aufeinander folgende Absätze auch besser als Liste auszeichnen.
frase wrote:Bis das alles mal soweit ist, habe ich mit hi_admin experimentiert.
Danke! Gefällt mir nicht schlecht.
frase wrote:Ich habe das Plugin nur soweit angepasst, damit es unter XH 1.7.x grundlegend funktioniert. Template- und CSS-Bearbeitung funktioniert nicht.
Da gibt es wohl zwei Probleme: einmal wurde der Konstruktor von XH_TextFileEdit in die PHP5-Variante __construct() umbenannt. Um dieser Änderung Rechnung zu tragen, müsste in plugins/hi_admin/templateeditor.inc.php in HI_adm_TextFileEdit::HI_adm_TextFileEdit() die letzte Zeile von

Code: Select all

        parent::XH_TextFileEdit(); 
in

Code: Select all

        parent::__construct(); 
geändert werden.

Zudem müsste die Nutzung des Codeeditor Plugins überarbeitet werden – die (eigentlich private) Funktion codeeditor_config() wurde entfernt. Als Quick-Fix kann man unter Plugins → Codeeditor → Konfiguration → enabled das Häkchen entfernen. Dann hat man zwar nur noch eine einfache Textarea, aber die Bearbeitung aller Templates und Stylesheets ist dann wieder möglich.
frase wrote:Mit hi_admin könnte man ausloten, was geht und was nicht - für eine spätere Generalüberholung des XH-Adminbereichs.
Gleichzeitig entstünde ein gutes Plugin, das wahlweise eingesetzt werden könnte (bis zur Überführung in XH).
Die Idee des Auslotens gefällt mir sehr – ist ja bei Pfw_XH und Fa_XH eigentlich nichts anderes.
frase wrote:Der Filebrowser ist einfach nicht vernünftig zu stylen. Poor, Need work!
Ich persönlich mag die Variante nicht, dass manches per <?php ?> Tags, und anderes per %PLATZHALTER% ins Template eingefügt werden kann (ist bei XH-Shop ähnlich, wobei man zumindest dort beide Varianten sogar alternativ verwenden kann). Und natürlich gefällt mir auch nicht, dass in den Filebrowser-Templates bisweilen zu komplexes PHP verwendet wird. Das hat aber eigentlich mit dem Gestalten nichts zu tun. Was stört dich konkret?
lck wrote:Ich meinte eigentlich, dass bei ausgeschalteten Contenteditor auch das Select-Menü von Nutzen wäre, bei manchen Templates bestimmt. Weniger Kickerei. Aber das wäre wieder etwas für Holger, eine Option hinzuzufügen "Select-Menü immer anzeigen",
Zurzeit wird dieses Select-Menü wohl per hiAdmSelectNav() im Template erzeugt (könnte man nicht XH\Pages::linkList() verwenden?); man könnte es aber auch direkt im Plugin erzeugen lassen, und es an $bjs. anhängen
Christoph M. Becker – Plugins for CMSimple_XH

frase
Posts: 5085
Joined: Thu Apr 21, 2016 6:32 am
Location: Saxony
Contact:

Re: Spezielles Administrationstemplate

Post by frase » Sat Nov 25, 2017 8:42 am

Uups. Da gibt es wieder viel zu antworten.

Zunächst möchte ich euch erstmal wieder auf den neuesten Stand bringen.
Hier die aktuellste Version des Admin-Templates. Einfach im Template-Odner ersetzen:
hi-admin_01---02.zip
Und, ich muss wohl nochmal erklären, was das Ganze eigentlich soll.
Also:
Ziel ist es, die Bedienoberfläche von XH zu modernisieren und zu vereinheitlichen.
Wenn möglich, sollten bisher bestehende Style-Konflikte vermieden werden.
Holgers hi_admin-Plugin bedient den zweiten Punkt schon ziemlich gut.
Ich stelle mir vor, dass am Ende zumindest die wichtigsten Elemente des Plugins in den Core übernommen werden.
Ich bin allerdings kein Programmierer. Deshalb konzentriere ich mich hier darauf, das spätere Aussehen des Adminbereichs zu simulieren und zu präsentieren - als Möglichkeit/Angebot.
Die (alters historisch bedingten) Schwächen von hi_admin kann und werde ich nicht korrigieren.
Auch Problemstellen im Core rühre ich nicht an (bis auf die kleine Korrektur in admin.min.js).
Was ich momentan tue ist, mithilfe eines Templates alles soweit hinzubiegen, dass man sich vorstellen kann, wie es später mal aussehen könnte. Dabei ist das Plugin eine gute Hilfe - und sollte es schiefgehen, ist nichts kaputtgemacht.
Dann könnte man mit anderen Templates weitermachen, bis eine Lösung gefunden ist, die allen gefällt.
cmb wrote:Hm, diese Feinheiten erscheinen mir überflüssig bzw. nicht wirklich passend. Ich denke, es sollte genügen (und sehr viel Flexibilität ergeben), wenn Plugins ihre Ausgabe in ein <div class="…"> einschließen ...
Es geht ja nicht nur um Plugins, sondern auch um den Core.
Beispiel:
Bei beinahe allen Konfig-Optionen steht am Ende: <input class="submit" value="Sichern" type="submit">
Bei "Passwort ändern" steht am Ende: <button name="action" value="save">Sichern</button>
Also einmal Input und einmal Button.
Mit "Regeln für Programmierer" meinte ich, dass sowas vereinheitlicht werden könnte/sollte.
Das Admin-Template könnte letztendlich auch dazu dienen ein "Style Guide" zu bieten, wo jeder sehen kann was passiert/ wie sieht es aus, wenn Input oder Button ... usw. verwendet wird.
Außerdem müssen auch die Listen unter "Einstellungen", "Plugins", "Links prüfen" ... usw. irgendwie benannt werden - zum unterscheiden.
cmb wrote: (betrifft Filebrowser)
Das hat aber eigentlich mit dem Gestalten nichts zu tun. Was stört dich konkret?
Gar nichts. Ich habe es nur nicht geschafft den Filebrowser wie die anderen Sachen "optisch umzubiegen" (Icons ...).
Das ist zu diesem Zeitpunkt aber auch gar nicht nötig. Die Templates will ich nicht anfassen, es soll ja erstmal alles bleiben wie es ist und auch ohne Admin-Template sauber weiter funktionieren.
(Beim Pagemanager konnte ich eingreifen - gesehen?)
cmb wrote:Zurzeit wird dieses Select-Menü wohl per hiAdmSelectNav() im Template erzeugt (könnte man nicht XH\Pages::linkList() verwenden?); man könnte es aber auch direkt im Plugin erzeugen lassen, und es an $bjs. anhängen
Richtig.
Bin mir allerdings immer noch nicht ganz sicher, ob das wirklich viel Nutzen bringt. Theoretisch sollte das Seiten-Template auch im Admin-Modus ein bedienbares Menü bieten.
Allerdings: Sollte das verschiebbare Select-menü standardmäßig immer vorhanden sein, dann könnten sich Template-Entwickler darauf verlassen ...
You do not have the required permissions to view the files attached to this post.

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Spezielles Administrationstemplate

Post by cmb » Sat Nov 25, 2017 12:30 pm

frase wrote:Ich stelle mir vor, dass am Ende zumindest die wichtigsten Elemente des Plugins in den Core übernommen werden.
Okay. Aber bevor das passiert sollte schon sehr detailliert klar sein, welche diese wichtigsten Elemente genau sind. Ich möchte nämlich Abstimmungen vermeiden, bei denen eigentlich völlig unklar ist, wie die Lösung aussehen soll – das ist leider in der Vergangenheit einige Male passiert, und hat später viel Zeit und Nerven gekostet.

Daher fände ich es schon sehr sinnvoll, wenn hi_admin auf die gewünschte Funktionalität zurecht gebogen wird, und wenn Details, die eigentlich wenig mit einem eigenständigen Adminmenü zu tun haben, am besten separat behandelt werden, wie eben:
frase wrote:Bei beinahe allen Konfig-Optionen steht am Ende: <input class="submit" value="Sichern" type="submit">
Bei "Passwort ändern" steht am Ende: <button name="action" value="save">Sichern</button>
Also einmal Input und einmal Button.
Mit "Regeln für Programmierer" meinte ich, dass sowas vereinheitlicht werden könnte/sollte.
Da stimme ich zu. Vermutlich werden nicht alle Pluginentwickler mitziehen, aber vielleicht einige, und zumindest im Core kann es ja einheitlich gehalten werden.

Meine Meinung zu <button type="submit"> vs. <input type="submit">: letzteres ist obsolet, und sollte gar nicht mehr verwendet werden. <button> bietet viel mehr sinnvolle Möglichkeiten, und wird längst von allen irgendwie relevanten Browsern unterstützt (IE ≥ 8, und selbst IE 7 zumindest grundlegend). Und dank <button> erübrigt sich auch der <input type="image"> Hack, der leider noch häufig zu finden ist.
frase wrote:Außerdem müssen auch die Listen unter "Einstellungen", "Plugins", "Links prüfen" ... usw. irgendwie benannt werden - zum unterscheiden.
Zumindest großenteils ließe sich das doch mit einem Einschließen in ein <div class="…"> wie oben erwähnt lösen. Da müssten nur alle Fälle herausgesucht werden, und sobald man sich auf geeignete Klassennamen geeinigt hat, könnte ein Pull-Request ausgearbeitet werden. Hängt jedenfalls nicht vom Admintemplate ab. Und letztlich könnten diese Änderungen auch einzeln durchgeführt werden.
frase wrote:Ich habe es nur nicht geschafft den Filebrowser wie die anderen Sachen "optisch umzubiegen" (Icons ...).
Das ist zu diesem Zeitpunkt aber auch gar nicht nötig. Die Templates will ich nicht anfassen, es soll ja erstmal alles bleiben wie es ist und auch ohne Admin-Template sauber weiter funktionieren.
Ist natürlich eine Prioritätsfrage, aber auch hier könnte die Darstellung des Filebrowsers schon konkret angegangen werden – ganz unabhängig von einem Admintemplate.

Ich bin halt nach wie vor der Meinung, dass es besser ist, kleine, gut überschaubare Einzelpunkte zu adressieren, anstatt gleich alles auf einen Schlag lösen zu wollen. :)
Christoph M. Becker – Plugins for CMSimple_XH

frase
Posts: 5085
Joined: Thu Apr 21, 2016 6:32 am
Location: Saxony
Contact:

Re: Spezielles Administrationstemplate

Post by frase » Sat Nov 25, 2017 12:45 pm

Erstaunlich. Bin mit allen deinen Punkten einverstanden ;-)
cmb wrote:Daher fände ich es schon sehr sinnvoll, wenn hi_admin auf die gewünschte Funktionalität zurecht gebogen wird
+1
cmb wrote:Meine Meinung zu <button type="submit"> vs. <input type="submit">: ...
Okay, ich finde Button auch besser.
Allerdings gibt es z.B. den Fall Einstellungen->Konfiguration ganz unten:
zwei Buttons, die evtl. per Klasse unterschieden werden müssen.
Das ist die Art "Regel", die mir vorschwebt.
Und da genügt es nicht, dass nur einer benannt wird, sondern alle.
Vielleicht alle Speichern-Buttons = primary
und weitere = secondary ... ?

Alles in allem ist es schon gut so, dass wir hi_admin haben.
Wir können all diese Dinge ausdiskutieren und testen - ohne Plugins oder Core ändern zu müssen.
Schaunmermal wie das ausgeht.

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Spezielles Administrationstemplate

Post by cmb » Sat Nov 25, 2017 12:57 pm

frase wrote:Okay, ich finde Button auch besser.
Allerdings gibt es z.B. den Fall Einstellungen->Konfiguration ganz unten:
zwei Buttons, die evtl. per Klasse unterschieden werden müssen.
Das ist die Art "Regel", die mir vorschwebt.
Und da genügt es nicht, dass nur einer benannt wird, sondern alle.
Vielleicht alle Speichern-Buttons = primary
und weitere = secondary ... ?
Buttons, die die Form-Submission auslösen, sind <button type="submit"> (wobei submit der Standardwert ist); andere Buttons sind <button type="button"> (oder <button type="reset">) – da könnte man doch entsprechend stylen.
Christoph M. Becker – Plugins for CMSimple_XH

frase
Posts: 5085
Joined: Thu Apr 21, 2016 6:32 am
Location: Saxony
Contact:

Re: Spezielles Administrationstemplate

Post by frase » Sat Nov 25, 2017 1:10 pm

Ah, danke. Ich vergaß.

Post Reply