nicht angemeldet
TS
Gunnar Bittersmann
TS
Gunnar Bittersmann
TS
Gunnar Bittersmann
TS
Gunnar Bittersmann
TS
Hallo,
ich habe ein Feedback-Formular, welches mit 5 Radiobuttons ausgestattet ist für jede der 4 Fragen.
Ich möchte nun, wenn 2 der Radiobuttons ausgewählt wurden, ein Textfeld (<textarea></textarea>) anzeigen lassen, jedoch sollen diese auch wieder verschwinden, wenn man eine andere auswahl gemacht hat.
Ich weiß, dass das mit JavaScript zu verwirklichen ist, jedoch habe ich in diesem Bereich keine Kenntnisse und habe auch nichts gefunden, dass mir bisher geholfen hat.
Kann mir diesbezüglich jemand helfen?
Anbei der Code der Radiobuttons (PHP):
echo '<tr><td><b>Sind Sie zufrieden mit unserem Service?</b></td>';
for ($i = 1; $i < 6; $i++) {
echo '<td align="center"><input type="radio" name="service" value="'.$i.'"';
if ($_POST['service'] == $i || (!isset($_POST['service']) && $i == 3)) {
echo ' checked="checked"';
}
if ($i > 4) {
echo ' onclick="function(#bereich1)"';
}
echo ' /></td>';
}
echo '</tr>
Vielen Dank :)
Hallo und guten Tag,
ich habe ein Feedback-Formular, welches mit 5 Radiobuttons ausgestattet ist für jede der 4 Fragen.
Ich möchte nun, wenn 2 der Radiobuttons ausgewählt wurden, ein Textfeld (<textarea></textarea>) anzeigen lassen, jedoch sollen diese auch wieder verschwinden, wenn man eine andere auswahl gemacht hat.
möchtest Du das nun clientseitig regeln, oder gestattest Du pro Aktion einen Roundturn zum Server, sodass es mit PHP geregelt werden könnte?
Es ist immer hilfreich, wenn man sich erst einmal einen genauen PAP (Programmaublaufplan) davon macht, in dem z.B. links die Clientaktionen und rechts die Server_re_aktionen stehen. Dann kann man auch besser sehen, an welchen Stellen man JavaScript links zur Unterstützung einbauen kann, damit dann rechts die Serverreaktionen zusammenschrumpfen bzw. wegfallen können.
Das Formular (eigentlich sind es ja mehrere in Folge) sollte dann auch noch ohne JavaScript funktionieren können!
@Gunnar würde da sicherlich "progressive Enhancement" als Methodik ins Spiel bringen und dabei würde ich ihn unterstützen ;-)
Zu deiner eigentlichen Frage fallen mir die Stichworte "Event Listener" und "Objekteigenschaften in JavaScript und CSS" ein. Dazu findest Du mit der Suche etliche Anregungen. Ich such auch nochmal für Dich, aber das dauert auch...
Grüße
TS
@@TS
Das Formular (eigentlich sind es ja mehrere in Folge) sollte dann auch noch ohne JavaScript funktionieren können!
Darüber streiten die Geister; siehe den ersten von 1unitedpowers Lesetips. 👻 Und vor allem Jeremy Keith’ Artikel Choise.
Aber ja, hier bin ich bei dir.
@Gunnar würde da sicherlich "progressive Enhancement" als Methodik ins Spiel bringen und dabei würde ich ihn unterstützen ;-)
Progressive enhancement hieße hier, dass das Textfeld ohne JavaScript immer sichtbar ist und erst mit JavaScript ausgeblendet wird.
LLAP 🖖
@@RavenPixel
ich habe ein Feedback-Formular, welches mit 5 Radiobuttons ausgestattet ist für jede der 4 Fragen.
Ich möchte nun, wenn 2 der Radiobuttons ausgewählt wurden,
Welche zwei?
ein Textfeld (<textarea></textarea>) anzeigen lassen, jedoch sollen diese auch wieder verschwinden, wenn man eine andere auswahl gemacht hat.
Ich weiß, dass das mit JavaScript zu verwirklichen ist
Eventuell auch ohne. Wie sieht dein Markup aus?
Anbei der Code der Radiobuttons (PHP):
echo '<tr><td><b>Sind Sie zufrieden mit unserem Service?</b></td>';
Es ist nicht die beste Idee, Markup mit PHP echo zu generieren.
Nicht HTML in PHP schachteln, sondern andersrum: Markup normal schreiben und nur die veränderlichen Daten mit PHP reinschreiben.
Kontrollstrukturen in der alternativen Schreibweise.
<tr><td><b>Sind Sie zufrieden mit unserem Service?</b></td>
<?php for ($i = 1; $i < 6; $i++): ?>
<td align="center"><input type="radio" name="service" value="<?= $i ?>"
<?php if ($_POST['service'] == $i || (!isset($_POST['service']) && $i == 3)):
checked="checked"
<?php endif; ?>
<?php if ($i > 4):
onclick="function(#bereich1)"
<?php endif; ?>
/></td>
<?php endfor; ?>
</tr>
Etwaige JavaScript-Fehler hab ich hier nicht berichtigt. HTML-Fehler auch nicht: Das b-Element ist falsch verwendet – Styling mit CSS. Und nach einer Tabelle sieht das auch nicht aus.
LLAP 🖖
Hallo und guten Tag,
Es ist nicht die beste Idee, Markup mit PHP
echozu generieren.Nicht HTML in PHP schachteln, sondern andersrum: Markup normal schreiben und nur die veränderlichen Daten mit PHP reinschreiben.
Thema Kontrollstrukturen: Da bin ich nun total anderer Meinung. Das kann später niemand mehr lesen. Außerdem ist HTML keine Programmiersprache und hat daher im Controller nichts zu suchen.
Ich propagiere daher eine andere Vorgehensweise:
Diese Vorgehensweise hat den Vorteil, dass die HTML- und CSS-Anweisungen durch einen Frontend-Designer erstellt werden können, der aber keinerlei Zugriff auf die eigentliche Programmlogik erhält. Er kann bestenfalls auswählen, durch welches Programmmodul die Daten für sein Template aufbereitet werden sollen. Dieses wählt dann auch automatisch die passenden Ersetzungsmethoden aus. Da könnte man den DOM-Parser dann auch gegen einen anderen austauschen, wenn nciht mehr HTML als Resultat herauskommen soll, sondern eine andere Beschreibungssprache.
Grüße
TS
@@TS
Es ist nicht die beste Idee, Markup mit PHP
echozu generieren.Nicht HTML in PHP schachteln, sondern andersrum: Markup normal schreiben und nur die veränderlichen Daten mit PHP reinschreiben.
Thema Kontrollstrukturen: Da bin ich nun total anderer Meinung. Das kann später niemand mehr lesen. Außerdem ist HTML keine Programmiersprache und hat daher im Controller nichts zu suchen.
Kontrollstrukturen (if, for) != Controller.
Kontrollstrukturen können natürlich im View auftreten:
Und durch den Wegfall der echos und des Escapens von Anführungszeichen ist das besser auch lesbar.
Man verwendet PHP einfach als Templatesprache wie Smarty o.ä.
Ich propagiere daher eine andere Vorgehensweise:
- Statische Inhalte des Dokumentes mit HTML (, CSS) und ggf. zur Not noch mit Platzhaltern
- Daten mittels PHP und Datenbank berechnen
- berechnete Daten mittels PHP an die passenden Stellen im HTML schreiben.
Das ist keine andere Vorgehensweise, sondern genau das, was ich sagte.
Das funktioniert entweder ganz HTML/CSS-konform mit der ID und dem DOM-Parser von PHP oder eben, für einfachen Zusammenhang mit den Platzhaltern (str_replace() mit Arrays).
Warum kompliziert, wenn’s auch einfach geht? Einfach mit echo jeweils an der entsprechenden Stelle (So wie mit geschweiften Klammern in anderen Templatesprachen.)
- Revolvierende Ausgaben, wie Tabellen, Listen usw. lassen sich dann allerdings sinnvoll nur noch mit dem DOM-Parser erstellen.
Warum kompliziert, wenn’s auch einfach geht? Dazu sind Kontrollstrukturen da, s.o. (So wie mit geschweiften Klammern in anderen Templatesprachen.)
Das zu wiederholende Element ist einmal in der Vorlage enthalten
Eben. Siehe mein Beispiel.
LLAP 🖖
Hallo und guten Tag,
Und durch den Wegfall der
echos und des Escapens von Anführungszeichen ist das besser auch lesbar.Man verwendet PHP einfach als Templatesprache wie Smarty o.ä.
Damit hat der Template-Entwickler Zugriff auf den PHP-Interpreter und damit auch den Server. Das ist unerwünscht.
Ich propagiere daher eine andere Vorgehensweise:
- Statische Inhalte des Dokumentes mit HTML (, CSS) und ggf. zur Not noch mit Platzhaltern
- Daten mittels PHP und Datenbank berechnen
- berechnete Daten mittels PHP an die passenden Stellen im HTML schreiben.
Das ist keine andere Vorgehensweise, sondern genau das, was ich sagte.
Das funktioniert entweder ganz HTML/CSS-konform mit der ID und dem DOM-Parser von PHP oder eben, für einfachen Zusammenhang mit den Platzhaltern (str_replace() mit Arrays).
Warum kompliziert, wenn’s auch einfach geht? Einfach mit
echojeweils an der entsprechenden Stelle (So wie mit geschweiften Klammern in anderen Templatesprachen.)
Weil sonst der HTML-Template-Entwickler Zugriff auf den PHP-Interpreter und damit auch den Server hat.
- Revolvierende Ausgaben, wie Tabellen, Listen usw. lassen sich dann allerdings sinnvoll nur noch mit dem DOM-Parser erstellen.
Warum kompliziert, wenn’s auch einfach geht? Dazu sind Kontrollstrukturen da, s.o. (So wie mit geschweiften Klammern in anderen Templatesprachen.)
Weil sonst der HTML-Template-Entwickler Zugriff auf den PHP-Interpreter und damit auch den Server hat.
Grüße
TS
@@TS
Damit hat der Template-Entwickler Zugriff auf den PHP-Interpreter und damit auch den Server. Das ist unerwünscht.
Von was für einem Szenario sprichst du hier?
Dass ein Frontend-Entwickler ein Template erstellt und es dann über den Zaun zum Backend-Entwickler wirft? Webentwicklung nach dem Wasserfallprinzip?
Das ist unerwünscht. So hat man vor 10 Jahren entwickelt, heute sind interdisziplinäre Teams angesagt.
Dass ein Entwickler Zugang zu richtigen Nutzerdaten hat, weil auf diesen entwickelt wird?
Das ist unerwünscht. Mehr als das, das sollte (darf) nicht sein. Zum Entwickeln hat man Testdaten.
LLAP 🖖
Hallo und guten Nachmittag Gunnar,
Damit hat der Template-Entwickler Zugriff auf den PHP-Interpreter und damit auch den Server. Das ist unerwünscht.
Von was für einem Szenario sprichst du hier?
Dass ein Frontend-Entwickler ein Template erstellt und es dann über den Zaun zum Backend-Entwickler wirft? Webentwicklung nach dem Wasserfallprinzip?
Das ist unerwünscht. So hat man vor 10 Jahren entwickelt, heute sind interdisziplinäre Teams angesagt.
Dass ein Entwickler Zugang zu richtigen Nutzerdaten hat, weil auf diesen entwickelt wird?
Ich spreche von dam ganz häufigen Fall, dass Foren und Portalseiten zusammengebastelt werden, bei denen der Enduser selber ein Profil oder Teile von Seiten erstellen kann, in denen dann auch HTML erlaubt sein kann.
Da ist es nicht sinnvoll, wenn das dann noch durch den PHP-Parser laufen soll. Anders ließen sich aber die dynamischen Inhalte, die der User anordnet, nach deiner Methode nicht zu ersetzen.
Grüße
TS
Damit hat der Template-Entwickler Zugriff auf den PHP-Interpreter und damit auch den Server. Das ist unerwünscht.
Von was für einem Szenario sprichst du hier?
Z.B. davon, dass Kunden vielleicht selber an Ihren Templates rumbasteln dürfen. Auf einem Multiuser-System. Da möchte man womöglich vermeiden, dass er einen Systemcall "rm -rf /" absetzt, um mal nur ein Beispiel zu nennen. Wie vermeidet man das? Mit einem Templatesystem ohne direkten Zugriff auf verwendete Sprache.
Gunnar, dass das im Deinem Wohlfühlszenario (es sei Dir gegönnt) nicht zutrifft, mag ja sein. Aber bitte nicht immer pauschale Aussagen zu Themen hinwerfen, die Du außerhalb Deines Kontexts nicht einschätzen kannst.
@@Mitleser
Damit hat der Template-Entwickler Zugriff auf den PHP-Interpreter und damit auch den Server. Das ist unerwünscht.
Von was für einem Szenario sprichst du hier?
Z.B. davon, dass Kunden vielleicht selber an Ihren Templates rumbasteln dürfen.
Kunde ist Webentwickler? Ich sehe da mehrere Möglichkeiten:
Kunde hat Ahnung. Dann kann er rumbasteln wie er will, ist aber für auftretende Fehler verantwortlich.
Kunde hat weniger Ahnung. Dann verwendet man eine Templatesprache (Smarty o.ä.).
Kunde hat gar keine Ahnung. Dann kann er statische HTML-Dateien als Vorlage erstellen, aus denen ein Entwickler dann die richtigen Seiten baut.
Keine der Möglichkeiten widerspricht dem von mir vorher Gesagtem. Hab ich noch eine vergessen?
LLAP 🖖
Hallo und guten Abend Gunnar,
- Kunde hat gar keine Ahnung. Dann kann er statische HTML-Dateien als Vorlage erstellen, aus denen ein Entwickler dann die richtigen Seiten baut.
So ähnlich sieht das in der Praxis aus. Der Kunde kann mittels Weiterentwicklung vom CK-Editor HTML-Bodies oder Teile davon erstellen. Die werden dann im Backend ins Dokument eingefügt und das DOM geprüft und der "automatische Webentwickler" fügt dann über die DOM-Funktionen noch automatisch die Daten hinzu nebst fehlendem HTML (meistens nur die revolvierenden Teile).
Grüße
TS
@@TS
- Kunde hat gar keine Ahnung. Dann kann er statische HTML-Dateien als Vorlage erstellen, aus denen ein Entwickler dann die richtigen Seiten baut.
So ähnlich sieht das in der Praxis aus. Der Kunde kann mittels Weiterentwicklung vom CK-Editor HTML-Bodies oder Teile davon erstellen. Die werden dann im Backend ins Dokument eingefügt und das DOM geprüft und der "automatische Webentwickler" fügt dann über die DOM-Funktionen noch automatisch die Daten hinzu nebst fehlendem HTML (meistens nur die revolvierenden Teile).
„Kunde hat gar keine Ahnung“ steht in eklatantem Widerspruch zu „kann HTML-Bodies oder Teile davon erstellen, die dann im Backend automatisch ins Dokument eingefügt werden“.
Das ist dann wohl das SISO-Prinzip: Shit in, shit out.
LLAP 🖖
Kunde ist Webentwickler? Ich sehe da mehrere Möglichkeiten: "1": Kunde hat Ahnung. Dann kann er rumbasteln wie er will, ist aber für auftretende Fehler verantwortlich.
"1a": Kunde hat Ahnung, ist aber ein pöser Pube. Er produziert keinen Fehler, kann Dank Zugriff auf den Server aber fremde Daten auslesen / manipulieren. Nein, das lässt sich nicht stimmig über die Server-Konfiguration abfangen.