Eingaben nach submit durch function erhalten

V

VJayy

New member
ID: 458947
L
2 Oktober 2014
2
0
Hallo liebe Coder-Gemeinde,

ich bin neu hier und kenne mich mit Java noch echt nicht wirklich gut aus.
Hoffentlich könnt ihr mir helfen. Ich verzweifel bald ^^

Und zwar habe ich im folgenden eine kleine Textarea. In dieser kann der Benutzer einen Text eingeben. Nebenan wird der eingegebene Text direkt geschrieben und angezeigt.

Nun kann man den Text in der Farbe ändern. Sobald man jetzt aber ein submit ausführen würde, wäre der Text wieder in der Ursprungsfarbe. Das soll aber nicht passieren.

Wie kann ich es erreichen, dass der Text nach einem submit immer noch in der vorher gewählten Farbe erhalten bliebe?

PHP: 
<script type="text/javascript">
function changeColor(color, box)
{
document.getElementById(box).style.color = color;
}
</script>

<textarea rows="5" cols="40" name="Eingabe" id="Eingabe" onKeyUp="setText(this.value, 'Infobox')" style.color="changeColor(this.value, 'Infobox')">Ihr Text</textarea>

<div style="padding:10px; background-color:#999999; overflow:auto;" id="Infobox">Ihr Text</div>

<select name="farbe" onChange="changeColor(this.value, 'Infobox');">
<option value="#000000"<?=$_POST[farbe] == "#000000" ? "selected" : "";?>>Schwarz</option>
<option value="#ffffff"<?=$_POST[farbe] == "#ffffff" ? "selected" : "";?>>Weiß</option>
<option value="#fbec47"<?=$_POST[farbe] == "#fbec47" ? "selected" : "";?>>Gelb</option>
</select>


Vielen lieben Dank schon einmal für eure Hilfe
 
Cookie verwenden:

Code: 
<html><head>
<script type="text/javascript"><!--
function changeColor(color, box) {
    document.getElementById(box).style.color = color;
    document.cookie = "color="+color;
}

function getColor() {
    if (document.cookie) {
        var c = document.cookie.indexOf("=") + 1; // "color=" übergehen
        color = document.cookie.substring(c);
        changeColor(color, 'Infobox');
    } 
}
--></script>
</head>
<body onload="javascript:getColor();">	
....

Cookies werden als Textschnipsel gespeichert ("c1=wert1;c2=wert2; ..."), document.cookie enthält immer die komplette Liste. Wenn Du mehrere verwendest mußt Du beim Einlesen also entsprechend mehr Aufwand treiben um das richtige Paar zu erwischen.

https://javascript-workshop.de/buch/08.html
https://wiki.selfhtml.org/wiki/JavaScript/Anwendung_und_Praxis/cookies

---

Übrigens: Es handelt sich nicht um Java sodern um JavaScript. :mrgreen:
 
Zuletzt bearbeitet:
Vielen Dank für deine Hilfe :)

Was mache ich denn aber nun mit der function getColor(); ???
Wo rufe ich diese denn wieder auf, damit die Farbe in dem Text erhalten bleibt?

Bekomme es irgendwie nicht hin :(
 
Der Aufruf erfolgt automatisch (Zeile 17: onload=...) wenn die Seite geladen wird. Von Tippfehlern mal abgesehen kann dabei eigentlich nichts schiefgehen. Soweit die Theorie...

---

Laß das onload-Gedöns probeweise weg und stell den Code hinter (!) die Liste:

Code: 
...
<select name="farbe" onChange="changeColor(this.value, 'Infobox');">
<option value="#000000"<?=$_POST[farbe] == "#000000" ? "selected" : "";?> > Schwarz</option>
<option value="#ffffff"<?=$_POST[farbe] == "#ffffff" ? "selected" : "";?> > Weiß</option>
<option value="#fbec47"<?=$_POST[farbe] == "#fbec47" ? "selected" : "";?> > Gelb</option>
</select>
<script type="text/javascript">
if (document.cookie) {
    document.write('<p>Cookie: '+document.cookie+'</p>');
    var c = document.cookie.indexOf("=") + 1;
    color = document.cookie.substring(c);
    changeColor(color, 'Infobox');
} 
</script>

(Der document.write()-Auruf dient nur zur Veranschaulichung.)

Wenn der Hoster und/oder sonstige eigebundene Skripte (zB. Werbepartner) eigene Cookies setzen reicht es nicht in document.ccokie nach einem '=' zu suchen und den Text dahinter als Farbwert zu benutzen. Man muß vorher das gesuchte Paar (hier: den Teilstring 'color=#ffffff') aus document.cookie rauspuhlen ohne dabei auf irgendwelche anderen Farbvorgaben (zB. 'textcolor=green;selectedtextcolor=blue;highlightedcolor=red; ...' aus Homepagebaukästen oÄ) reinzufallen. 'color' ist als Name also nur bedingt geeignet.
 
Wenn ich mir diesen "Code" so ansehe, werde ich ganz traurig, da wurden von Leuten "gelernt", die selber keine Ahnung haben und der größte Bullshit wird weiter verbreitet, ohne sich auch nur 1 x auf php.net schlau zu machen. Was sind das für Tag-Bereiche? Wo lernt man solchen Mist? Naja, solange in der Apache-Config steht, das "short_open_tags" = 1 ist, läuft so etwas ja auch, wenn man dann noch das Error-Reporting in der Entwicklung komplett abschaltet (falls es überhaupt eingeschaltet war), sieht man auch nicht die Fehlerhaften Zuweisungen der Array-Keys, echt traurig, wenn man so blind jeden Mist übernimmt und sich danach "Programmierer" schimpfen will.
 
440ci schrieb:
Wenn ich mir diesen "Code" so ansehe, werde ich ganz traurig, da wurden von Leuten "gelernt", die selber keine Ahnung haben und der größte Bullshit wird weiter verbreitet, ohne sich auch nur 1 x auf php.net schlau zu machen. Was sind das für Tag-Bereiche? Wo lernt man solchen Mist? Naja, solange in der Apache-Config steht, das "short_open_tags" = 1 ist, läuft so etwas ja auch, wenn man dann noch das Error-Reporting in der Entwicklung komplett abschaltet (falls es überhaupt eingeschaltet war), sieht man auch nicht die Fehlerhaften Zuweisungen der Array-Keys, echt traurig, wenn man so blind jeden Mist übernimmt und sich danach "Programmierer" schimpfen will.
Zum Vergrößern anklicken....
Immer erst an die eigene Nase fassen...

1. Seit PHP 5.4 ist <?= standardmäßig integriert, ohne short_open_tags aktiviert zu haben. Also erstmal auf php.net schlau machen, bevor du rumpöbelst.
2. short_open_tag (de)aktiviert man primär in der php.ini und nicht in der Apache-Config (auch wenn es php_admin_value gibt, gehört es primär dort nicht hinein)
3. Jeder hat mal klein angefangen.
 
flaschenkind schrieb:
Immer erst an die eigene Nase fassen...

1. Seit PHP 5.4 ist <?= standardmäßig integriert, ohne short_open_tags aktiviert zu haben. Also erstmal auf php.net schlau machen, bevor du rumpöbelst.
2. short_open_tag (de)aktiviert man primär in der php.ini und nicht in der Apache-Config (auch wenn es php_admin_value gibt, gehört es primär dort nicht hinein)
3. Jeder hat mal klein angefangen.
Zum Vergrößern anklicken....

Die Unsinnige Tag-Einleitung "<?=" ist nicht integriert, dieser Quatsch wird einfach nur ignoriert, ganz egal wie "short_open_tags" eingestellt wird.
Du hältst es also für "rumpöpeln", wenn 1 hier auf einen Fehler hinweist, wo alle anderen 7,3 Mio wegschauen?

Ich habe auch mal klein Angefangen, das war schon unter PHP 4.0.x gewesen, aber damals wurden gängige Tags nicht verstümmelt, sondern so geschrieben, das sie auch einen gültigen Bereich einleiten,- muß wohl daran gelegen haben, das ich Scripte von Leuten hatte, die Ahnung von der Materie hatten und nicht irgendwas per Copy&Paste zusammen gefrickelt habe.
Komischerweise sieht man solche Verstümmelungen immer nur in solchen Communitys, welche "Programmieren" eher unter "ferner liefen" halten sollten, aber niemals auf Seiten, die sich mit "ernsthaften" PHP-Scripten schmücken.

Ich habe rein zufällig noch das allererste Script, welches ich überhaupt mal geschrieben habe...aber selbst da habe ich solchen Unfug nicht veranstaltet...und das war im Jahre 2001 unter PHP 4.x, also rund 14 Jahre her. Selbst dort habe ich schon auf eine Absicherung, gescheite Deklaration und Initialisierungen geachtet.

PHP: 
<?PHP

/////////////////////////////////////////////////////////////////////////
/*									*/
/*             Copyright (c) 2001 by xxxxxxx				*/
/*				@					*/
/*		https://www.benutzerfehler.de				*/
/*									*/
/*  Das Script darf Erweitert und angepasst,				*/
/*  das Copyright aber nicht entfernt oder				*/
/*  in irgendeiner Weise verändert werden.				*/
/*									*/
/*									*/
/*  Entwickelt für das PHP-Nuke 5.x-System				*/
/////////////////////////////////////////////////////////////////////////

if (!eregi("modules.php", $PHP_SELF)) {
    die ("Zugriff verweigert");
}

require_once("mainfile.php");
$module_name = basename(dirname(__FILE__));
include("header.php");
$index = 0;
 
440ci schrieb:
Die Unsinnige Tag-Einleitung "<?=" ist nicht integriert, dieser Quatsch wird einfach nur ignoriert, ganz egal wie "short_open_tags" eingestellt wird.
Zum Vergrößern anklicken....
Interessante Ansichtsweise. "Dieser Quatsch" ist für reine PHP-Templates gar nicht so unsinnig, da es die Lesbarkeit um ein Vielfaches erhöht, wenn man <?= $foo ?> statt <?php echo $foo; ?> schreiben kann. Ist ja nicht umsonst integraler Teil des Kerns geworden...

Selbst short_open_tags sind für diesen Anwendungsfall in meinen Augen sogar sehr gut, da komplexere Templates mit vielen, zum Teil verschachtelten <?php schnell unübersichtlich werden. Ist minimal, aber darauf kommt es manchmal an, wenn man sich mal durch hunderte Zeilen Code wühlen muss.

Letztendlich ist es doch auch Geschmackssache.

Zum Rest: Hier in diesem Forum ging es sehr oft um Lösungen, die erstmal funktionieren. Oftmals wollen die Fragesteller gar nicht wirklich so viel programmieren, sondern sie haben gerade akut ein Problem und sind für jede Hilfe dankbar, die funktioniert. Der Hintergrund, wieso und weshalb es funktioniert, interessiert oft nicht. Da mit der Keule der reinen Lehre zu argumentieren, bringt wenig. Wer richtig programmieren will, wird früher oder später schon über error_reporting() und sein error_log stolpern.

Sich insgesamt wegen so'nem Pillepallekram aufzuregen, ist der Mühe nicht Wert. Ansonsten müsste man auch noch anfangen, zu kritisieren, dass Inline-Skripte bäh sind und DOM Level 0 Event Handler heutzutage auch eher in die "Da war ja mal was"-Schublade gepackt werden sollten. ;)
 
tleilax schrieb:
Interessante Ansichtsweise. "Dieser Quatsch" ist für reine PHP-Templates gar nicht so unsinnig, da es die Lesbarkeit um ein Vielfaches erhöht, wenn man <?= $foo ?> statt <?php echo $foo; ?> schreiben kann. Ist ja nicht umsonst integraler Teil des Kerns geworden...
Zum Vergrößern anklicken....

PHP ist eine Hochsprache, welche dem C in vielen Bereichen sehr nahe kommt, allerdings wird dir eine falsche Schreibweise im C einen sofortigen Absturz der Applikation präsentiert, weil es dort nicht gestattet ist, irgendwas zu schreiben, dort muß alles Hand und Fuß haben.
PHP dagegen ist in vielen Bereichen gutmütig genug, den Quatsch, welchen der Interpreter aufgetischt bekommt, auszubügeln,- so lange es funktioniert, sind natürlich alle im Glauben, es wäre richtig so zu schreiben, deshalb kann man auch Array-Keys unbehandelt zu Konstanten wandeln, Interger zu Strings, ja sogar String zu Interger.
Schaltet man dann sein Error-Reporting auf E_ALL | E_STRICT ein, wird man recht schnell sehen, was geht und was nicht geht

tleilax schrieb:
Selbst short_open_tags sind für diesen Anwendungsfall in meinen Augen sogar sehr gut, da komplexere Templates mit vielen, zum Teil verschachtelten <?php schnell unübersichtlich werden. Ist minimal, aber darauf kommt es manchmal an, wenn man sich mal durch hunderte Zeilen Code wühlen muss.
Zum Vergrößern anklicken....

Die Möglichkeit, Stylesheets in eine Datei auszulagern, gibt es bestimmt schon 10 Jahre, wieso werden solche Erleichterungen nicht genutzt? Und wer soll solchen Code heute noch gescheit warten sollen?

Solange es reiner PHP/HTML/JS-Code ist und sich nicht als wirren und unübersichtlichen Haufen, wo von allem etwas wild durcheinander gewürfelt ist, wo für JS und PHP die Tags mit "<?" beginnen, ist alles ok... Scripte, welche so aussehen, womöglich noch ohne Description, Einrückungen und Leerzeichen daher kommen, landen bei mir schon seit Jahren in der Tonne

tleilax schrieb:
Letztendlich ist es doch auch Geschmackssache.

Zum Rest: Hier in diesem Forum ging es sehr oft um Lösungen, die erstmal funktionieren. Oftmals wollen die Fragesteller gar nicht wirklich so viel programmieren, sondern sie haben gerade akut ein Problem und sind für jede Hilfe dankbar, die funktioniert. Der Hintergrund, wieso und weshalb es funktioniert, interessiert oft nicht. Da mit der Keule der reinen Lehre zu argumentieren, bringt wenig. Wer richtig programmieren will, wird früher oder später schon über error_reporting() und sein error_log stolpern.
Zum Vergrößern anklicken....

Genau das ist nämlich der Punkt: Die Leute, die nur ein Problem gelöst haben wollen, wissen gar nicht, was sie da eigentlich "Programmieren"...sie bekommen irgendwelchen (womöglich noch fehlerhaften) Code aufgetischt, welchen sie (blind vertrauend) mit Copy&Paste irgendwo rein bauen, den Hauch von Ahnung haben die aller wenigsten, das ganze wird dann irgendwo auf einen Webserver geladen und der 1. Einbruch über ein solches Script erfolgt 2 Tage später...eventuell wird der angemietete VPS übernommen und das nächste Topic ist hier


tleilax schrieb:
Sich insgesamt wegen so'nem Pillepallekram aufzuregen, ist der Mühe nicht Wert. Ansonsten müsste man auch noch anfangen, zu kritisieren, dass Inline-Skripte bäh sind und DOM Level 0 Event Handler heutzutage auch eher in die "Da war ja mal was"-Schublade gepackt werden sollten. ;)
Zum Vergrößern anklicken....

Hast du dir schon mal die Vertragsdaten deines Hosters durchgelesen, wie hoch deine Haftung beim Einbruch durch die von dir installierte (fehlerhafte) Software sein kann? Das ist für mich alles andere als "pillepallekram"

Inline-Scripte gibt es bei mir nicht, dafür habe ich seit rund 4 Jahren eine PHP-Klasse, welche mir benötigte externe Scripte und Form-Elemente einbindet,- hat den Vorteil: Ich muß nur an 1 Stelle etwas ändern (zb. größe der Textarea o.ä.) und habe es im ganzen System aktiv:

PHP: 
                            <?php echo $this->doc->setFormElement (array (
                                'type' => 'select',
                                'name' => 'mail_engine',
                                'value' => $this->conf->mail_engine,
                                'start' => 0,
                                'end' => 1,
                                'title' => 'SELECT_MAIL_ENGINE',
                                'event' => 'onChange',
                                'event_function' => '__js_switch_mail_engine',
                                'id' => 'mail_engine'
                            )); ?>
 
Mir steht der Sinn gar nicht so nach einer grossen Diskussion oder gar Schwanzvergleich. Vor allem nicht, wenn es eigentlich um Äpfel geht und dann mit einem Mal Bananen und Birnen reingeworfen werden.

Ich sehe in dem Codeschnippsel, um den es hier ging, keine einzige Sicherheitslücke. Und die darin enthaltenen "Probleme" sind zwar nicht das unbedingt das Gelbe vom Ei, aber letztendlich vollkommen unkritischer Pillepallekram. Über nix Anderes habe ich urteilen wollen.
 
Um mal wieder zurück zum Thema zu kommen:

Das POST-Array lässt sich (nach dem prüfen und escapen) am besten als neues Array in der Session weiter reichen, so kannst du es an jeder x-beliebigen Stelle innerhalb des Scriptes nutzen, ohne es jedes mal erneut in den globalen Scope zu packen.
Das gilt natürlich nur, solange die Session aktiv und gültig ist.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben