Newsletter: Default-Wert des Adress-Input-Feldes über Sprachvariablen defineren

[ghost]

Das Template nl_default.tpl' sieht vor, einen Default-Wert für das Input-Feld der E-Mail-Adresse auszugeben ($this->email). Im ModulModuleSubscribe` wird dieser Wert fest auf '' gesetzt. Würde diese Modulvariable statt dessen mit einer Sprachvariable initialisiert werden, könnte man auf diese Weise einfach Hinweistexte wie 'Geben Sie hier Ihre E-Mail-Adresse ein' umsetzen (die dann per JavaScript auf '' gesetzt werden, sobald man in das Feld klickt).

Ich habe dies im angehängten Git-Patch umgesetzt. Die Variable $GLOBALS['TL_LANG']['MSC']['emailValue'] wird als Default-Wert für $this->Template->email in ModuleSubscribe.php verwendet. Die Variable wird in newsletter/de/default.php bzw. in newsletter/en/default.php auf '' gesetzt.

Download the attachments

--- Originally created by phelan on April 11th, 2011, at 10:19pm (ID 3003)

[aschempp]

Wenn ich mich richtig erinnere, ist der "Standardwert" dazu da, die Email Adresse bei einer falschen Eingabe wieder auszugeben. Hast du das bei deinem Patch berücksichtigt?

--- Originally created on April 12th, 2011, at 08:17am

[ghost]

Danke für die rasche Bearbeitung! Ich kann nicht bestätigen, dass die E-Mail-Adresse bei abgelehnter Validierung wieder ausgegeben wird. Die Variable 'email' des Template-Objekts wird nur in der Zeile 135 der Datei ModuleSubscribe.php auf '' gesetzt und in diesem Modul nicht weiter verwendet. Sie wird dann nur mehr im Template ausgelesen. Vielleicht ist sie eingeführt, um sie wieder in dem von Dir angesprochenen Fall auszugeben. Derzeit ist das aber, soweit ich den Code überblicke und in meiner Contao-Installation getestet habe, nicht implementiert.

Sollte das noch einbaut werden, sollte das nicht mit dem Patch kollidieren, da nur der Anfangswert statt mit '' eben mit einer Sprachvariable (die per default ebenfalls mit '' initialisiert wird) gesetzt wird. Just another added level of indirection.

PS: In welchem Format kann / soll man Dir Patches schicken? Ich vermute, Du verwendest svn als VCS?

--- Originally created by phelan on April 12th, 2011, at 11:29am

[ghost]

Anbei der mit SVN erzeugte Patch.

--- Originally created by phelan on April 12th, 2011, at 12:02pm

[aschempp]

Interessant, ich kann den Sinn dieser Übergabe auch nicht erkennen. Allerdings bezweifle ich dass wir einen Leeren Sprach-String setzen sollten, sondern eher das ganze Konstrukt entfernen. Wenn jemand einen Standardwert setzen will, kann er das auch direkt im Template machen.

--- Originally created on April 12th, 2011, at 12:43pm

[ghost]

Die Variable wird im Fall, dass man sich aus einer Liste austrägt, mit der GET-Variable 'email' befüllt. Das Konstrukt macht also durchaus Sinn. Wenn man also das Template verändert und dort direkt einen Sprachstring ausliest, beraubt man sich dieser 'unsubscribe'-Logik.

--- Originally created by phelan on April 12th, 2011, at 02:24pm

[aschempp]

Das ist aber nur im Unsubscribe-Modul der Fall, nicht im Subscribe-Modul?

--- Originally created on April 12th, 2011, at 03:13pm

[ghost]

Ja, da aber beide Module auf das selbe Template zurückgreifen, muss die Variable email auch im Subscribe-Module gesetzt werden. Sie wird dort einfach mit '' initialisiert und nicht weiter verwendet, daher die scheinbare "Nutzlosigkeit" des Konstrukts.

--- Originally created by phelan on April 12th, 2011, at 03:16pm

[aschempp]

Womit wiederum eine mögliche Vorbelegung über die Sprachdatei Sinn machen würde?

--- Originally created on April 12th, 2011, at 03:35pm

[ghost]

Ja, ich denke schon. Es müsste halt klar sein, was damit bezweckt ist.

Ich habe diesen Weg gewählt, um im Eingabefeld ein 'Enter your e-mail address here' / 'Bitte geben Sie hier ihre E-Mail Adresse ein' anzuzeigen, das geleert wird, wenn der User in das Feld klickt.

Ich sehe derzeit keinen Nachteil, diese eine zusätzliche Sprachvariable einzuführen. Man könnte sie vielleicht 'emailValueDefault' nennen, damit ihr Sinn klarer herauskommt. Die Variable würde einfach eine weitere Konfigurationsmöglichkeit eröffnen.

In wie weit diese Einsatzmöglichkeit, die ja auf JavaScript angewiesen ist, mit Barrierefreiheit zusammengeht, kann ich nicht beurteilen.

--- Originally created by phelan on April 12th, 2011, at 04:14pm

[aschempp]

Ich sehe allerdings ein Problem wenn die Email per URL übertragen wird, weil dann der On-Click-Leeren auch greift?

--- Originally created on April 12th, 2011, at 04:16pm

[ghost]

Das ist nur eine Frage, wie "intelligent" man den JavaScript-Code schreibt.

Ich habe mir meinen Zugang nochmal überlegt und habe eine relativ einfache Möglichkeit gefunden, das gewünschte Verhalten nur über eine Änderung des Templates nl_default.tpl zu erreichen. Und zwar ersetze ich einfach die Ausgabe echo $this->email; durch if ($this->class == "mod_subscribe"): echo $GLOBALS['TL_LANG']['MSC']['emailValue']; else: echo $this->email; endif;.

Damit habe ich denselben Effekt nur über die Änderung von Sprachfiles und des Templates erreicht.

Ich würde daher dafür plädieren, das Ticket zu schließen und die Änderung abzulehnen.

--- Originally created by phelan on April 12th, 2011, at 04:33pm

[leofeyer]

--- Originally closed on August 23rd, 2011, at 04:52pm