Select Box mit metadata settings (4.6.2)

Hallo,

wie kann ich per metadata settings array eine Selectbox erzeugen und dabei das label internationalisieren Also sowas wie:

array(
            'group' => 'UG_FLEXIPAY_SETTINGS_POA_TITLE',
            'name' => 'ugFlexipayCfgPoa5KZ',
            'type' => 'arr',
            'value' => array (
                1 => 'ugFlexipayCfgPoa5KZ1'
            )
 ),

1 ist dann der Wert und ugFlexipayCfgPoa5KZ1 würde dann übersetzt werden in ein Label was in meiner Languagedatei steht.

Ich habe noch zwei andere Fragen :-). Wie kann man die Reihenfolge der Settingseinträge festlegen? Ich habe es einfach so gemacht das ich Zahlen im name Feld verwende. Dadurch wird die Reihenfolge festgelegt. Schön ist das aber nicht.

Kann ich Languagefiles nun auch in den Modulordner packen oder müssen diese noch im Shop (out Ordner) liegen?

Wäre super wenn ihr wenigstens ein paar der Fragen beantworten könntet.

Grüße,
Stephan Räder

das hier kennst Du?

Klar. Aber da steht aber leider nichts was mir weiterhilft. Die Doku scheint mir da unvollständig zu sein.

also im Endeffekt willst du für die <options> value und den Anzeigetext getrennt von einander definieren?

[QUOTE=vanilla thunder;94402]also im Endeffekt willst du für die <options> value und den Anzeigetext getrennt von einander definieren?[/QUOTE]

Klar. Oder gibt es eine andere Möglichkeit?

Ich kram das hier mal vor, weil:

Wie kann man die Reihenfolge der Settingseinträge festlegen? Ich habe es einfach so gemacht das ich Zahlen im name Feld verwende. Dadurch wird die Reihenfolge festgelegt. Schön ist das aber nicht.

das interessiert mich auch gerade brennend! Wie ist der aktuelle Stand der Dinge?

Danke + Gruß!

edit: ups, ist ja noch gar nicht so alt der thread, ich war gerade halb auf engl. datum gepolt (7.4.)… :smiley:

für ein <select> musst du “type” => “select” eintragen und dann genau so die language idents “SHOP_MODULE_varname” in der language Datei eintragen.

eine Möglichkeit zum eigenen Sortieren habe ich nicht gefunden, man könnte ein Modul schreiben und die Modulverwaltung von OXID erweitern um die Einstellungen zu sortieren oder falls die Klasse nicht überladbar ist, die Settings-Einträge mit Smarty im Template sortieren. Aber das alles wäre wohl nicht wirklich sauberer als die Lösung mit den Zahlen im Namen

Ha, ich hab’s (und diesmal sogar ohne Modul)! :smiley:

Habe nämlich vorhin mal den Code zum Aktivieren der Module durchwühlt, wobei dann irgendwann der Groschen fiel. Im Prinzip ist es total einfach, es fehlt bloß in der Wiki-Doku:
Es gibt auch die Möglichkeit die Felder “constrains” (typo, soll wohl constaints heißen) und “position” mit in die Settings-Liste aufzunehmen, coole Sache!!! Damit ist die Sortierung schon mal geklärt und die Select-Boxen auch halbwegs. Bei letzteren muss man halt entscheiden, ob man gleich die gewünschten Values speichert (macht nur mit ASCII Sinn) oder erstmal nur laufende Nummern, die man später im Modul umwandelt. Ich habe mich an “iNewBasketItemMessage” orientiert und für Zahlen entschieden, damit man eben keine Umlautprobleme bekommt und die lang-Einträge kürzer/übersichtlicher hält.

Hier ein Beispiel:

array( 'group' => 'main', 'name' => 'sConfigTest', 'type' => 'select', 'value' => '0', 'constrains' => '0|1|2|3', 'position' => 3 )

Dazu passend muss dann in die lang.php:

'SHOP_MODULE_sConfigTest'        => 'Feldbeschreibung',
'SHOP_MODULE_sConfigTest_0'      => '',
'SHOP_MODULE_sConfigTest_1'      => 'Wert x',
'SHOP_MODULE_sConfigTest_2'      => 'Wert y',
'SHOP_MODULE_sConfigTest_3'      => 'Wert z'

Im Endeffekt gespeichert wird bei Auswahl dann halt nur die Zahl (“value” ist der Defaultwert)…

Klasse, es hapert also nur ein wenig an der Doku, ansonsten gut gemacht das Ganze! Eine kleine Abrundung könnte noch sein, den Input-Feldern ein “size” und “maxlength” mitgeben zu können, aber das wäre nur noch Kosmetik. :wink:

kannst Du das im Wiki ergänzen?

Ich hatte es fast schon befürchtet… :wink:
Aber ehrlich gesagt, wüsste ich auf die Schnelle nicht, wie man dort am besten ansetzt, und dann noch in möglichst korrektem englisch. Der ganze Settings-Abschnitt müsste viel ausführlicher sein und am besten untergliedert, aber ich habe noch nie mit Wikis gearbeitet, im Ernst. :o

Ein bisschen fehlt mir gerade die Zeit und Muße, mich da auch noch reinzudenken, sorry. Aber wenigstens ein Beispiel-Array mit diesen beiden Optionen sollte schon dazu, dann kann man sich den Rest evtl. auch zusammenreimen. Es ginge aber sicher schneller, wenn dies jmd. anderes übernähme.

Auch wäre dieser Schreibfehler (contrains) evtl. noch ein Thema. Nicht, dass man es nun öffentlich verbreitet und in einem baldigen OXID-Patch wird das noch korrigiert (was eigentlich sinnvoll wäre, um Verwirrungen zu vermeiden). Dazu müsste man dies aber fast als Bug melden, etwas übertrieben, oder?

mach Du den Bug - ich mach das Wiki

Arbeitsteilung, okay :wink:
Aber ich weiß doch eben nicht, ob es ein Bug in dem Sinne ist. Außerdem mag es auch andere Coder geben, die das selbst herausfanden und in Ihrem Modulen bereits nutzen. Ich hätte ungern die Verantwortung, wenn durch meine Meldung nun wieder alle Module angepasst werden müssten. Hm, na gut, man könnte einfach beide Versionen abfragen, aber die Entscheidung liegt ja nicht bei mir.
Auch müsste das Wiki dann wieder angepasst werden, falls Du es jetzt schon integrierst, das verpennen wir sicherlich wieder… :wink:

Okido, damit die Debatte nicht völlig versandet, habe ich doch mal eben einen Bug [https://bugs.oxid-esales.com/view.php?id=4255] eingetragen und bin auf Resonanz seitens OXID gespannt. Davon hängt ja erstmal das weitere Vorgehen ab…

Aha, eben kam eine resolved-Meldung zum Bugeintrag rein! Soll also per Patch behoben sein, und der ist ja fast schon überfällig. Damit ist der Typo wohl in Kürze aus der Welt, was sicher nicht schadet. Fragt sich noch, wie es nun genau gefixt wurde, damit man es im Wiki (evtl. versionsanhängig) korrekt beschreiben kann.
Auch denke ich, dass man diesen Thread mit diesem hier “verknüpfen” sollte, und als Ergebnis das nette Demo-Modul von vanilla thunder um verschiedene Settings ergänzt und dann im Wiki verlinkt, oder so. Evtl. noch die integrierte Admin-Blocks-Demo etwas abmildern, da der JS-alert auf Dauer bisschen nervt, aber ansonsten eine gute Idee so ein Anschauungsmodul mit allen Extras! :slight_smile:

das JS alert ist ja das beste an dem Modul :smiley:

lol, na gut, eigentlich schon!
so gibt es wenigstens nicht den geringsten Zweifel, dass es funktioniert… :smiley:

@vanilla - Du kannst das Modul ja ins Wiki reinpacken, am Besten wohl unter Tutorials und dann im Wikibeitrag Features verlinken

ich werde das js alert wirklich ausbauen (bin eben fast durchgedreht :smiley: ) und dann noch paar andere Features einbauen.
Bestimmte wünsche diesgezüglich?

(omg 1000+ :smiley: bei 1337 höre ich aber auf)

Glückwunsch! :slight_smile:
Und da wir ja in diesem Thread sind, müssen natürlich settings rein, mit mind. einer selectbox und den positions, sonst wüsste ich auch erstmal nicht. Allerdings macht es wohl Sinn, erstmal den Patch abzuwarten, oder hast du in den trunk geschielt (falls es dort schon drin ist)? Obwohl, wahrscheinlich egal, da es in Zukunft wohl wieder constraints heißen wird, aber man müsste dann halt erwähnen, dass das Modul erst ab OXID 4.6.3(?) läuft. Hm, irgendwie habe ich das Gefühl, dass meine Bugmeldung es nun unnötig verkompliziert hat, und evtl. hätte man es einfach bei contrains belassen sollen… :wink:

EDIT:
Tja okay, Patch 4.6.3 ist da, aber leider wohl noch ohne diesen Fix, wenn ich das richtig sehe.

Übrigens wurde es ja letztens in Version 4.6.4 (abwärtskompatibel) gefixt, also könnte man ab es nun im Wiki mit dem korrekten “constraints” beschreiben… :slight_smile: