mehrzeilige textareas statt einzeilige inputs?!!

[Underdog]

Ich verstehe nicht, warum in der 1.5./1.5.1- Version mehrzeilige textarea-Felder nun in der CMS configuration editor statt die alten einzeiligen input-Felder verwendet werden, auch für Felder (z.B. Show_homepage:, Folders, Backup: Numberoffiles) in denen nur ein Wort oder Zahl Sinn hat!

Das erschwert außerdem auch den Sicherungsvorgang, denn mit den input-Feldern konnte man früher einfach durch Drucken der Enter-Taste Änderungen der Einstellungen einfach sichern; mit mehrzeiligen textarea-Feldern werden statt dessen neue Zeilen eingefügt.

Was sind die Gründe dafür?

[cmb]

Hallo Underdog,

in den Vorgängerversionen waren die Inputs für die Bearbeitung der Meta-Tags und einiger Sprachstrings sehr unschön. Die Bearbeitung der Einstellungen für CMS, Website und Sprache wird aber von einer gemeinsam genutzten Code-Routine durchgeführt. Um das nun nicht komplett umzustellen, haben wir die Textareas erst mal für alle Einstellungen gesetzt. Immerhin werden diese je nach Textlänge einzeilig bzw. mehrzeilig ausgegeben. Die Enter-Taste "funktioniert" nun zwar nicht mehr, aber dafür wurde noch ein "Sichern"-Schalter oben ergänzt. Außerdem werden die Einstellungen bei der Plugin-Konfiguration und der Plugin-Sprache auch schon immer (?) als Textareas dargestellt, so dass es nun etwas einheitlicher ist.

Die Lösung ist sicher nicht der Weisheit letzter Schluß, aber ich denke, für's erste insgesamt eine Verbesserung, um eben auch lange Texte bearbeiten und sehen zu können. Und irgendwo mussten wir den Schlußstrich für 1.5 ziehen. Für die nächste Version sollte das vielleicht noch einmal grundlegend überarbeitet werden, so dass dann individuell Inputs, Textareas wie auch Checkboxen und Selects angezeigt werden.

Und eigentlich wird die Konfiguration ja auch nicht häufig bearbeitet werden müssen. In der Regel reicht es ja, wenn dort einmalig alles eingestellt wird.

Christoph

[Underdog]

Danke für die schnelle Antwort, Christoph!

die Inputs für die Bearbeitung der Meta-Tags und einiger Sprachstrings sehr unschön.

Das stimmt, natürlich!

Die Bearbeitung der Einstellungen für CMS, Website und Sprache wird aber von einer gemeinsam genutzten Code-Routine durchgeführt. Um das nun nicht komplett umzustellen, haben wir die Textareas erst mal für alle Einstellungen gesetzt....Die Lösung ist sicher nicht der Weisheit letzter Schluß, aber ich denke, für's erste insgesamt eine Verbesserung, um eben auch lange Texte bearbeiten und sehen zu können.

Hmm... die Umwandlung von einer Unschönheit für manche Felder in eine andere (auch unlogischere!) Unschönheit für andere Felder ist eine fragwürdige "Verbesserung":

1. Die meisten Einstellungen für CMS sind von Typ Boolean, integer oder ein-Wort-string.
2. Von der Website-Konfigurationseinstellungen sind die mehrzeiligen Felder für Meta, Keywords und Description natürlich schöner.
3. Die Sprache-Einstellungen sind ja eine heiße Mischung aus Einzelwort-, einzeiligem- und mehrzeiligem Text, wo eine einheitliche "Lösung" programmiertechnisch sicherlich einfacher sei, aber auf Kosten der Korrektheit.

Jedoch freut es mich, dass diese Lösung nicht als letzte Weisheit betrachtet wird!

Die mehrzeilige Felder öffnen außerdem neue Fehlermöglichkeiten bei der Benutzereingabe: Habe gerade eine mehrzeilige Eingabe bei 'passwort' (ein Wort + 2x Enter "versehentlich" gedruckt) und "unbemerkt" gesichert, und schon kann ich mich nicht mehr einloggen, ohne die eine oder andere config-Dateien zu editieren. Allerdings lässt dieses Verhalten nicht immer reproduzieren. (Merkwürdig.)

Die Enter-Taste "funktioniert" nun zwar nicht mehr, aber dafür wurde noch ein "Sichern"-Schalter oben ergänzt.

Für mich persönlich leider ein schwacher Trost: Vor allem bei der lange Liste von Spracheinstellung ist dies sehr unpraktisch. Nun kann ich dazwischen entscheiden, ob ich nach ganz oben oder ganz unten scrollen mag, statt einfach eine Taste zu drucken.

Und eigentlich wird die Konfiguration ja auch nicht häufig bearbeitet werden müssen. In der Regel reicht es ja, wenn dort einmalig alles eingestellt wird.

Wenn dass so sei, dann hätten wir gerne bei der 1.4.x input-Felder genauso bleiben können, oder? Bei mir zumindest reicht eine einmalige Einstellung der Konfiguration kaum aus. Ich vergesse oder übersehe eine Einstellung, entdecke etwas Neues, schalte manche Funktionen vorübergehend aus oder ein, ändere die Sprache/n und schraube immer wieder dran, um Webseiten anzupassen.

Für die nächste Version sollte das vielleicht noch einmal grundlegend überarbeitet werden, so dass dann individuell Inputs, Textareas wie auch Checkboxen und Selects angezeigt werden.

Super! Es wäre ja sehr schön, wenn z.B. die Boolean-Optionen über radio-buttons und Listenoptionen als select-Boxen dargestellt werden (annähernd des TemPlugin-Stils und darüber hinaus)!
Spätestens bei 2.0. hoffentlich !
Michael

[Gert]

Es wäre ja sehr schön, wenn z.B. die Boolean-Optionen über radio-buttons und Listenoptionen als select-Boxen dargestellt werden (annähernd des TemPlugin-Stils und darüber hinaus)!
Spätestens bei 2.0. hoffentlich !

So ungefähr sieht es aus

Gert

PS: Wir haben das bereits vor Wochen sehr intensiv intern diskutiert, uns für die 1.5 aber erstmal für die bestehende Lösung entschieden.

[cmb]

Hallo Michael, hallo Gert,

ich bin gerade noch mal über dieses Thema gestolpert, und möchte noch ergänzen, dass die "Settings"-Formulare für den "Core" und die Plugins derzeit noch von zwei völlig getrennten Routinen erstellt und verarbeitet werden. Das sollte sich m.E. in der nächsten Version (aber nicht mehr für 1.5.x) ändern.

Diesbezüglich gab es letzten Sommer (wenn man auf's Thermometer schaut, klingt das so unendlich weit weg ) bereits eine Diskussion.

Es wäre ja sehr schön, wenn z.B. die Boolean-Optionen über radio-buttons und Listenoptionen als select-Boxen dargestellt werden (annähernd des TemPlugin-Stils und darüber hinaus)!
Spätestens bei 2.0. hoffentlich !

Das habe übrigens nicht ich geschrieben, sondern Michael, auch wenn ich mich durchaus anschließen möchte, dass es TemPlug_XH da besser macht, als der Core und der Pluginloader.

Christoph

[Gert]

Ui - ein Zitat-Fehler, andere ermahne ich bei sowas

Habe ich korrigiert.

auch wenn ich mich durchaus anschließen möchte, dass es TemPlug_XH da besser macht, als der Core und der Pluginloader.

Aber der Preis dafür ist, dass die Admin Oberfläche von Hand geschrieben werden muss, und sich nicht aus einem Array heraus generiert. Das hat aber bei TemPlug_XH noch andere Gründe,

Gert

[Underdog]

Von Re: (CMSimple_XH 1.4.2) CMSimple script prevents hide

Hallo Michael, Because you are the only one, who wants to have back the input fields instead textareas, we will not change it back. But we will improve the backend, to use checkboxes, selectboxes etc., but in a later version, not yet, Gert

Sagen wir mal, ich bin bisher der einzige, der sich die Mühe machte, einen Posten darüber zu schreiben... und das auf Deutsch. Vielleicht gibt es welche im englischen Sprachraum, die sich auf einen in English erfassten Posten anschließen würden.

Auf jeden Fall werden check-/selectboxen viele Felder abdecken, aber eine mehrzeilige textarea für z.B. das Email-Feld zur Aktivierung des Mailformulars ist nicht reine Geschmackssache; das habe ich aber bereits hier klar dargestellt.
Wenn es nicht der Mühe wert ist, die input-Felder dort wieder einzuführen, wo sie hingehören, dann halt nicht. Aber wenn man schon dabei ist, die anderen Feldformate auszubessern und korrekter, user-freundlicher darzustellen, warum dann auch nicht eben die ehemaligen input-Felder, die zusätzlich das Abspeichern durch Enter-Tastendruck erleichtern?!!

sigh
Michael

[cmb]

Hallo Michael,

Aber wenn man schon dabei ist, die anderen Feldformate auszubessern und korrekter, user-freundlicher darzustellen, warum dann auch nicht eben die ehemaligen input-Felder, die zusätzlich das Abspeichern durch Enter-Tastendruck erleichtern?!!

Die Konfigurations-Formulare werden schon "immer" wie folgt aufgebaut:

Code: Select all

Für alle Optionen:
    gibt das Eingabefeld mit dem aktuellen Wert aus

Ganz simpel! In der Praxis aber nicht wirklich. Der Code dafür erstreckt sich in adm.php von Zeile 248 - 407!Da ist dann auch gleich das Speichern mit abgedeckt, und der Code hat's wirklich in sich.

Wollte man nun unterschiedliche Options-Typen (checkboxen, selects, inputs, textareas) ermöglichen, dann müsste da noch einiges geändert werden (ähnlich wie die existierenden Selectboxen ab Zeile 379). Das haben wir uns aber mal für 1.6 aufgespart, da wir für 1.5 schon genügend andere neue Features eingebaut haben.

Der Wechsel zu den Textareas erscheint stringend, da das auch in den Plugin-Konfigurationsdialogen so gemacht wird. Richtig ist allerdings, dass in der eigentlichen Konfiguration (Einstellungen->Settings) keine einzige Textarea gebraucht wird.

Sagen wir mal, ich bin bisher der einzige, der sich die Mühe machte, einen Posten darüber zu schreiben

Ja, das ist wohl richtig. Und es hat wohl auch noch niemand explizit erwähnt, dass er die Textareas grundsätzlich besser findet.

aber eine mehrzeilige textarea für z.B. das Email-Feld zur Aktivierung des Mailformulars ist nicht reine Geschmackssache

Da gebe ich Dir völlig recht. Aber ein einzeiliges Input für die meta_description ist auch keine reine Geschmackssache.

Was also machen, da die individuellen Feldtypen für 1.5.x kein Thema sind? Nun, eigentlich ganz einfach: da ein expliziter Zeilenumbruch in keiner der Textareas sinnvoll ist (wenn ich nicht etwas übersehen habe), könnte man auch einfach den Enter-Key für Textareas aushebeln. Das sollte mit ein wenig JS machbar sein.

Wäre das für alle eine akzeptable Lösung?

Christoph

[Gert]

Wäre das für alle eine akzeptable Lösung?

Diese Art von Zwischenlösungen mag ich nicht.

Wir werden das sicher irgendwann optimal lösen, bis dahin gibt es keine Lösung, die sowohl dem gefällt, der öfters mal an der Konfiguration rumspielt, als auch dem, der öfter mal die Sprachdateien bearbeitet.

Ich habe ja bei TemPlug_XH und der neuesten Version von FotoGalerie_XH schon mal geübt

Gert

[Underdog]

da ein expliziter Zeilenumbruch in keiner der Textareas sinnvoll ist (wenn ich nicht etwas übersehen habe), könnte man auch einfach den Enter-Key für Textareas aushebeln. Das sollte mit ein wenig JS machbar sein. Wäre das für alle eine akzeptable Lösung?

Ich fände das eigentlich ein guter Kompromiss für ein 1.5.x update ! So wird der von den input-Feldern mitgebrachte Komfort wiederhergestellt!

ein einzeiliges Input für die meta_description ist auch keine reine Geschmackssache.

Gebe ich Dir auch recht! Gerd hat auch mal die Komplikationen der input vs. textarea bei den Sprachen erwähnt. Was sich auf der Oberfläche so einfach aussieht - vor allem die Umwandlung aller input-Felder in 1.4.x zu textarea-Feldern in 1.5 - ist untendrunter doch schwieriger! Entweder-So-Oder-So ist die Umsetzung relativ einfach; So-Und-So dagegen aufwendig.