Hallo,
auf den ersten Blick erscheint der von dir beschriebene Prozess schon recht einfach, aber eine genaueren Überprüfung hält er leider nicht statt.
Leider gibt es bei der Web-Entwicklung so viele Details zu berücksichtigen.
Versteckte Felder, also das Formularelement <input type="hidden"> sind dazu gemacht, Daten, die der Benutzer nicht sehen und verändern können soll, mit dem Formular zu übertragen.
Da es sich um ein Input-Element handelt sind "Daten" hier unstrukturierte Daten, insbesondere keine HTML-formatierten Daten, wie sie in E-Mail-Texten verwendet werden.
Und natürlich sind in einen <input type="hidden"> keine weiteren HTML-Elemente erlaubt.
Eine bedingte Anzeige macht bei versteckten Feldern keinen Sinn (sie sind per Definition immer nicht sichtbar) und ist deshalb bei der Entwicklung der bedingten Anzeige nie als eine mögliche Notwendigkeit auch nur in Betracht gezogen worden.
Der gesamte Code, der die bedingte Anzeige steuert, ist deshalb nicht bzw. nur mit sehr großem auf versteckte Felder erweiterbar.
(Die bedingte Anzeige von Feldern ist ein sehr komplexes Thema und deshalb auch ein ziemliches Alleinstellungsmerkmal von Visforms).
Der Weg den du vorschlägst würde beinhalten, dass man alle potentiellen E-Mail-Texte (versteckt) mit dem Formular transportiert.
E-Mail-Texte sind oft lang.
Du davon ausgehen, dass es dann auch Situationen gibt, in denen mehr als 2 alternative Texte verwendet werden.
Die gesamte Größe des Post-Requests ist aber limitiert und würde mit diesem unsichtbaren Inhalt erheblich aufgeblasen.
Es ist ja gerade der Trick, dass der wesentliche Teil des E-Mail-Textes nicht zum Client gesendet wird, um die Post-Request-Größe ausreichend klein zu halten.
Außerdem gibt es Sicherheitsbedenken.
In deiner Lösung erscheint der gesamte E-Mail-Text in der Seite (auch wenn unsichtbar) und kann durch bösartige Software komplett geändert werden.
Du kannst davon ausgehen, dass, sobald der individuelle E-Mail Text möglich ist, als nächstes auch die Anfrage nach den individuellen E-Mail-Anhängen kommt.
Es ist also leider wenig sinnvoll, einen ganz neuen aufwendigen zweiten Workflow zur logisch-steuerbaren Behandlung von E-Mail-Texten (mit recht begrenzter Funktionalität) zu implementieren.
Das schafft auch hauptsächlich nur Verwirrung im/am Source-Code und ist schwer zu warten.
Stattdessen müsste, wie oben bereits erwähnt, der bestehende E-Mail-Template-Workflow erweitert werden.
Herzliche Grüße,
Aicha