[e-spin_form-scr-default] - dyn. Standardwerte für Formularelemente "SCR"

[zonky]

dyn. Standardwerte für Formularelemente "SCR" - d.h. für Selectbox, Checkbox und Radiobutton

Die Standardwerte für die drei Elemente können bisher nur fest bzw. statisch vorgebenen werden - bei Elementen wie Textfelder ist es aber möglich, ein Standardwert über ein Insert-Tag dynamisch einzubinden

Mit der Erweiterung wird die dynamische Vorbelegung auch auf die o.g. Formularfeldtypen erweitert und so kann z.B. bei einer Auswahl an Anreden (Frau | Herr) beim erneuten Aufruf des Formulares erneut gesetzt werden.

Weitere Infos siehe www.e-spin.de/form-scr-default.html

Gruss

[Thomas]

Sicherlich von Vorteil, aber warum um alles in der Welt immer diese obskuren Bezeichnungen für Erweiterungen, die sich kein Mensch merken kann?

Sorry, dass Du derjenige bist, der es jetzt ab bekommt, aber mir ist das schon bei einigen Erweiterungen aufgefallen.
So toll einige Erwerterungen auch sind, ich persönlich finde nur die Hälfte davon tatsächlich wieder, wenn ich sie denn mal gebrauchen kann.
Ich finde es halt schade.

[andreasisaak]

Sicherlich von Vorteil, aber warum um alles in der Welt immer diese obskuren Bezeichnungen für Erweiterungen, die sich kein Mensch merken kann?

Sorry, dass Du derjenige bist, der es jetzt ab bekommt, aber mir ist das schon bei einigen Erweiterungen aufgefallen.
So toll einige Erwerterungen auch sind, ich persönlich finde nur die Hälfte davon tatsächlich wieder, wenn ich sie denn mal gebrauchen kann.
Ich finde es halt schade.

Muss ich dir vollkommen zustimmen. Die Zeiten von gut zu merkenden Extensions wie Avisota, Isotope, MetaModels oder syncCto sind wohl vorbei. Ich verstehe diesen Hang nicht immer seinen persönlichen Präfix an die Extension zu hängen. Das hat in diesem Thread direkt nichts zu suchen, aber diese Extension ist ein extremer Vertreter der neuen "Mode".

[zonky]

das eine Erweiterung über die Suche von contao.org gefunden werden kann, ist fast auszuschließen... ohne eine "externe Suche" - sprich google - ist man eh aufgeschmissen...

=> von daher ist der Name eher irrelevant

Wichtiger ist mir, dass es einen erklärenden Text bzw. eine Webseite zum Einsatz gibt - und die ist vorhanden ;-)

bei einigen Erweiterungen - ob ER oder Github - reicht die Erklärung/Beschreibung nicht über einen (nichtssagenden) Namen hinaus...

... ich habe die Kritik aber dennoch positiv aufgenommen

Gruss

[extractjan]

Hallo,

und erstmal vielen Dank für die Erweiterung - genau was ich gesucht habe!

Nun gibt es leider eine Fehlermeldung, und zwar beim Bearbeiten von EFG-Formulardaten.
Also leeres Formular/neuer Datensatz funktioniert, aber wenn ich einen vorhandenen bearbeiten will, kommt die Warnung.

Als Standardwert für ein Select-Menü setze ich einen Wert per Inserttag {{user::irgendwas}}
Contao 3.2.17
EFG 2.2.1

Ist das schonmal aufgetreten, oder hat jemand eine hilfreiche Idee?

Grüße,
Jan

Warning: preg_split() expects parameter 2 to be string, array given in system/modules/core/library/Contao/Controller.php on line 666

#0 [internal function]: __error(2, 'preg_split() ex...', '/homepages/37/d...', 666, Array)
#1 system/modules/core/library/Contao/Controller.php(666): preg_split('/\\{\\{(([^\\{\\}]*...', Array, -1, 2)
#2 system/modules/e-spin_form-scr-default/forms/FormSelectMenu.php(30): Contao\Controller->replaceInsertTags(Array)
#3 system/modules/efg/forms/ExtendedForm.php(390): FormScrDefault\FormSelectMenu->__set('value', Array)
#4 system/modules/core/classes/Hybrid.php(209): Efg\ExtendedForm->compile()
#5 system/modules/core/forms/Form.php(47): Contao\Hybrid->generate()
#6 system/modules/efg/modules/ModuleFormdataListing.php(3134): Contao\Form->generate()
#7 system/modules/efg/modules/ModuleFormdataListing.php(3018): Efg\ModuleFormdataListing->generateEditForm(Object(Contao\ContentModel), Object(Contao\Database\Mysqli\Result))
#8 system/modules/efg/modules/ModuleFormdataListing.php(713): Efg\ModuleFormdataListing->editSingleRecord()
#9 system/modules/core/modules/Module.php(139): Efg\ModuleFormdataListing->compile()
#10 system/modules/efg/modules/ModuleFormdataListing.php(476): Contao\Module->generate()
#11 system/modules/core/elements/ContentModule.php(54): Efg\ModuleFormdataListing->generate()
#12 system/modules/core/library/Contao/Controller.php(457): Contao\ContentModule->generate()
#13 system/modules/core/modules/ModuleArticle.php(187): Contao\Controller->getContentElement(Object(Contao\ContentModel), 'main')
#14 system/modules/core/modules/Module.php(139): Contao\ModuleArticle->compile()
#15 system/modules/core/modules/ModuleArticle.php(50): Contao\Module->generate()
#16 system/modules/core/library/Contao/Controller.php(393): Contao\ModuleArticle->generate(false)
#17 system/modules/core/library/Contao/Controller.php(255): Contao\Controller->getArticle(Object(Contao\ArticleModel), false, false, 'main')
#18 system/modules/core/pages/PageRegular.php(129): Contao\Controller->getFrontendModule('0', 'main')
#19 index.php(248): Contao\PageRegular->generate(Object(Contao\PageModel), true)
#20 index.php(431): Index->run()
#21 {main}

[zonky]

Also leeres Formular/neuer Datensatz funktioniert, aber wenn ich einen vorhandenen bearbeiten will, kommt die Warnung.

... bearbeiten im Frontend oder im Backend?

[extractjan]

Frontend.

[zonky]

hmmm... FEE habe ich beim EFG noch nie getestet :-(

[extractjan]

hmm ... müßte nicht eigentlich das Modul ignoriert werden, wenn schon ein Wert gesetzt ist? Nur so ein gedanke .....
Vielleicht finde ich noch ein paar Infos.

[zonky]

hmm ... müßte nicht eigentlich das Modul ignoriert werden, wenn schon ein Wert gesetzt ist?

ja - das macht Contao selbst - ist sozusagen das gleiche wie ausgefülltes Formularfeld aber (irgendeinde) Validierung hat angeschlagen - dann bleiben die Werte erhalten

[extractjan]

noch eine kleine Erkenntnis hinterher:
In der genannten Zeile
#2 system/modules/e-spin_form-scr-default/forms/FormSelectMenu.php(30): Contao\Controller->replaceInsertTags(Array)

wird offenbar der Inserttag nicht richtig ersetzt:

$varValue = $this->replaceInsertTags($varValue); 

So funktioniert es:

    $varValue = $this->replaceInsertTags(print_r($varValue,true)); 

hmm?

Unabhängig davon wird beim Bearbeiten von EFG-Formulardaten im Frontend der bereits gespeicherte Wert im Select-Menü nicht "selected".
... ich probier mal noch weiter ....

[zonky]

was steht in "$varValue"?

[extractjan]

Da steht der Inserttag {{user::irgendwas}}.

Komisch ist eben, daß er an der Stelle (bereits gespeicherte Daten) den Inserttag gar nicht anwenden soll,
und bei einem leeren Formular funktioniert es ja auch - der Inserttag wird richtig ersetzt.

[zonky]

gibt es einen - ggf. geschützten - Zugang zu der Webseite / Projekt?

kannst mich auch per PN an-pingen

[extractjan]

danke, aber ... so auf die Schnelle nicht.

Aber du hattest schon richtig nach $varValue gefragt -beim Bearbeiten der Daten steht dort nicht mehr Inserttag, sondern der gespeicherte Wert in einem Array.

Hab jetzt erstmal eine Notlösung, indem ich in der Funktion prüfe, ob wirklich ein String bzw Inserttag übergeben wird.
Nicht schön aber funktioniert:

    public function __set($strKey, $varValue)
    {
        
        if(is_string($varValue)) $is_inserttag = (substr($varValue,0,2)=="{{" && substr($varValue,-2)=="}}");
        else $is_inserttag = false;
        
        if ($strKey == 'value' && $is_inserttag)
        {
            $varValue = $this->replaceInsertTags($varValue,true);
        }
        
        parent::__set($strKey, $varValue);
        
  } 

Vielen Dank fürs mitdenken!

[zonky]

indem ich in der Funktion prüfe, ob wirklich ein String bzw Inserttag übergeben wird.

hätte gedacht, dass macht replaceInsertTags von sich aus...