Maxi: Formulardaten mit PHP und POST

Hallo liebe SelfHTML-Gemeinde,

ich bin dabei PHP zu lernen und möchte mir als kleinen "Test" ein Frage- und Antwort-Spielchen erstellen. Allerdings weiß ich nicht wie ich Daten aus einem alten Formular weitervermitteln kann. Mein Code sieht so aus:

---
Die Eingabe im letzten Formular war <? echo $HTTP_POST_VARS["frage1"]; ?>.<br/><br/>

<form name="Formular01" action="004.php" method="post">
<input style="margin-left:20px;" type="Text" name="frage2" value="" size="50" maxlength="" />
<input type="hidden" name="frage1" value="<? echo $HTTP_POST_VARS["frage1"]; ?>" />
<input type="Submit" name="" value="Fertig!" />
</form>
---

Wenn ich dies jedoch absende, kommt die neue Eingabe (frage2) problemlos an, aber die alte Information (frage1) bleibt hängen. Ich vermute mal, dass ich <? echo $HTTP_POST_VARS["frage1"]; ?> nicht einfach in das value von input einbauen darf - aber mir fällt kein anderer Lösungsweg ein wie man die alten Daten "durchschleifen" kann um sie später erneut zu verwenden.

Oder ist eine Lösung nur mit einer externen Datei möglich, wo man die Infos speichert?

  1. Entweder sessions, oder einfacher so (falls nicht sicherheitsrelevant):

    Folgende Schleife innerhalf Deines Formulares laufen lassen:

    foreach($_REQUEST as $key => $value) {
       echo '<INPUT type="hidden" name="'.$key.'" value="'.$value.'">';
    }

    1. Hallo Lithaila,

      vielen Dank für die schnelle Hilfe. Ich habe mich zwar für den Lösungsweg von werbeklaus entschieden, doch Deine Methode probiere ich auf jeden Fall auch noch aus!

  2. Hallo,

    Ich vermute mal, dass ich <? echo $HTTP_POST_VARS["frage1"]; ?> nicht einfach in das value von input einbauen darf.

    Natürlich darfst du sowas, denn PHP ist es doch egal, wo sowas steht; er schreibt das einfach. Und in HTML kommt dann (oder sollte :-) ein sinnvoller value-Wert raus.

    Ich vermute, es liegt einfach daran, dass
    $HTTP_POST_VARS[]
    einfach veraltet ist, und du lieber
    $_POST[]
    verwenden solltest :-)

    Viel Erfolg beim rumprobieren!
    werbeklaus

    1. Hallo werbeklaus,

      vielen Dank für die blitzschnelle und effektive Hilfe. Mit dem $_POST[] klappt es nun wunderbar! Noch einmal Danke!

  3. Hallo Maxi,

    um die Informationen von Lukas (werbeklaus) zu vervollständigen:

    Die Eingabe im letzten Formular war <? echo $HTTP_POST_VARS["frage1"]; ?>

    Bitte schaffe Dir eine neuere Quelle an, um PHP zu lernen. Bereits seit PHP 4.1.0 wird empfohlen, die neuen superglobalen Variablen zu nutzen.  Wenn ich mir die Release-Geschichte von PHP anschaue, so ist dies seit Dezember 2001 so, seit PHP 5.0, d.h. seit Juli 2004 ist es sogar möglich, die langen von PHP vordefinierten Arrays abzuschalten (siehe erster Link).

    Du solltest Dich über die Möglichkeiten PHP-Bereiche zu kennzeichnen, informieren. Du wirst sehen, dass die von Dir verwendete Methode

    <? [...] ?>

    nicht immer zur Verfügung steht, d.h. freigeschaltet werden muss

    <?php [...] ?>

    ist der empfohlene Weg.

    <input type="Submit" name="" value="Fertig!" />

    Es ist eine gute Idee, auch dem Submit-Button einen Namen zu geben.

    Freundliche Grüße

    Vinzenz

    1. Hi,

      Es ist eine gute Idee, auch dem Submit-Button einen Namen zu geben.

      warum?

      freundliche Grüße
      Ingo

      1. Hallo Ingo,

        Es ist eine gute Idee, auch dem Submit-Button einen Namen zu geben.
        warum?

        damit ich auf das Name-Value-Paar dieses Formularelements zugreifen kann.

        Freundliche Grüße

        Vinzenz

        1. Hallo,

          Es ist eine gute Idee, auch dem Submit-Button einen Namen zu geben.
          warum?

          damit ich auf das Name-Value-Paar dieses Formularelements zugreifen kann.

          Frage: warum sollte man darauf zugreifen?

          Um z.B. mehrere Submitbuttons für unterschiedliche Aktionen ermöglich zu können... :-)

          LG
          Chris

          1. Hallo Chris,

            Es ist eine gute Idee, auch dem Submit-Button einen Namen zu geben.
            warum?
            damit ich auf das Name-Value-Paar dieses Formularelements zugreifen kann.

            danke für das sinnvolle und

            Frage: warum sollte man darauf zugreifen?
            Um z.B. mehrere Submitbuttons für unterschiedliche Aktionen ermöglich zu können... :-)

            angebrachte Ergänzen meiner Antwort. Das hätte ich selbst dazuschreiben sollen (dürfen, können, müssen oder was auch immer sonst :-) ).

            Freundliche Grüße

            Vinzenz

            1. Hi,

              Frage: warum sollte man darauf zugreifen?
              Um z.B. mehrere Submitbuttons für unterschiedliche Aktionen ermöglich zu können... :-)

              angebrachte Ergänzen meiner Antwort. Das hätte ich selbst dazuschreiben sollen (dürfen, können, müssen oder was auch immer sonst :-) ).

              ja - dann hätte ich auch nicht nachgefragt. Denn für den Normalfall ist der Submit-Button irrelevant und dürfte meist sogar in der Auswertung etwas stören.

              freundliche Grüße
              Ingo

              1. Hallo Ingo,

                ja - dann hätte ich auch nicht nachgefragt. Denn für den Normalfall ist der Submit-Button irrelevant und dürfte meist sogar in der Auswertung etwas stören.

                da ich öfter mit "Affenformularen" arbeite, ist für mich die Auswertung des Submit-Buttons normal. Mich hat die Auswertung auch noch nie gestört, obwohl ich _immer_ meinem Submit-Button ein nichtleeres Name-Attribut verpasse. Könntest Du mir ein Beispiel geben?

                Freundliche Grüße

                Vinzenz

                1. Hi,

                  da ich öfter mit "Affenformularen" arbeite, ist für mich die Auswertung des Submit-Buttons normal.

                  Wieso? Ein "Affenformular" ist zunächst mal nur ein Formular, das sich (bzw. dieselbe Seite)  aufruft. Dazu braucht es nicht mehr als einen Submit-Button bzw. es ginge auch ohne.

                  Mich hat die Auswertung auch noch nie gestört, obwohl ich _immer_ meinem Submit-Button ein nichtleeres Name-Attribut verpasse. Könntest Du mir ein Beispiel geben?

                  Wenn Du z.B. ein universelles Formmailer-Script verwendest, das sämliche Werte weiterreicht - zwar überprüft, aber halt alle (zulässigen). Oder wenn Du ein zwar spezialisiertes Script verwendest, aber für verschiedene Formularseiten, in denen der Submit-Button unterschiedlich bezeichnet ist. Da ist es einfach ein klein wenig Mehraufand, dieses Wertepaar zu berücksichtigen.

                  freundliche Grüße
                  Ingo

                  1. Hallo,

                    ... und man sollte hier auch nicht vergessen, dass hier die Philosophie eine gewisse Rolle spielt. Es gibt schließlich immer noch die unterschiedlichen Verhaltensweisen der Browser, wenn man die Eingaben mit <RETURN> bestätigt.

                    Trotzdem sollte mMn jedes übertragbare Element des Forms auch einen Namen haben. Das ist einfach sauberer Programmierstil, oder muss ich hier sagen "Codierstil", weil doch HTML keine Programmiersprache ist? *gg*

                    LG
                    Chris

                    1. Hi,

                      Es gibt schließlich immer noch die unterschiedlichen Verhaltensweisen der Browser, wenn man die Eingaben mit <RETURN> bestätigt.

                      und die wären?
                      wenn der Submit-Button (immer vorausgesetzt, es gibt nur einen!) ein name-Attribut hat, sendet jeder mir bekannte Browser dieses Feld in beiden Fällen mit.

                      Trotzdem sollte mMn jedes übertragbare Element des Forms auch einen Namen haben.

                      Ich stimme zu, sofern es Felder sind, die zu einer Eingabe vorgesehen sind und auch für hidden Felder - sonst sollte man sie entfernen. Aber was habe ich oder der Nutzer des Formulars z.B. von der Übertragung der Information "Senden = Senden"? Solche eine Angabe ist einfach redundant.

                      freundliche Grüße
                      Ingo

                      1. Hallo,

                        Ich stimme zu, sofern es Felder sind, die zu einer Eingabe vorgesehen sind und auch für hidden Felder - sonst sollte man sie entfernen. Aber was habe ich oder der Nutzer des Formulars z.B. von der Übertragung der Information "Senden = Senden"? Solche eine Angabe ist einfach redundant.

                        Und Rendundanz ist ein beliebtes Mittel für Kontrolle :-)

                        LG
                        Chris

                        1. Hi,

                          Und Rendundanz ist ein beliebtes Mittel für Kontrolle :-)

                          soso... Du läßt eine Passworteingabe wohl auch sicherheitshalber dreifach wiederholen - um sicherzustellen, daß der Nutzer Copy&Paste auch wirklich beherrscht bzw. nicht aus der Übung kommt? ;-)

                          freundliche Grüße
                          Ingo

                          1. Hallo,

                            Und Rendundanz ist ein beliebtes Mittel für Kontrolle :-)

                            soso... Du läßt eine Passworteingabe wohl auch sicherheitshalber dreifach wiederholen - um sicherzustellen, daß der Nutzer Copy&Paste auch wirklich beherrscht bzw. nicht aus der Übung kommt? ;-)

                            Und Du verzichtest wohl generell auf eine Kopie von FAT oder sonstigen wichtigen Tabellen und wahrscheinlich auch auf die Datensicherung, da doch sowieso nichts passiert, oder?

                            Meine Antwort bezog sich auf den Eindruck den "Solche eine Angabe ist einfach redundant" vermitteln könnte. Redundanz ist von Haus aus nichts schlechtes.

                            LG
                            Chris

                  2. Hallo Ingo,

                    Mich hat die Auswertung auch noch nie gestört, obwohl ich _immer_ meinem Submit-Button ein nichtleeres Name-Attribut verpasse. Könntest Du mir ein Beispiel geben?
                    Wenn Du z.B. ein universelles Formmailer-Script verwendest, das sämliche Werte weiterreicht - zwar überprüft, aber halt alle (zulässigen).

                    in diesem Fall sehe ich keinen Unterschied. Der Submit-Button hat einen festgelegten Namen, daraus ergibt sich ein zugelassenenes Name-Value-Paar, das ich zwar zusätzlich berücksichtigen muss. Ein einziges Mal. Nein, hier sehe ich keinen Unterschied, damit auch keinen Nachteil.

                    Oder wenn Du ein zwar spezialisiertes Script verwendest, aber für verschiedene Formularseiten, in denen der Submit-Button unterschiedlich bezeichnet ist. Da ist es einfach ein klein wenig Mehraufand, dieses Wertepaar zu berücksichtigen.

                    Sicher, hier hast Du einen kleinen Mehraufwand. Für mich ist es ein Mehraufwand und eine Fehlerquelle, daran denken zu können, dass ich die Namensvergabe unterlassen könnte. Ich vermute, dass dies eine individuelle Vorliebe ist, die schwierig objektiv zu bewerten ist. Vergleichbar vielleicht mit dem Weglassen von Blockklammern in Konstrukten wie

                    if (Bedingung)
                        Anweisung;
                      else
                        Anweisung;
                      Anweisung;

                    Diese Schreibweise mag ich nicht, ich setze lieber immer Klammern. Andere lassen die Klammern immer weg, wenn sie nur können.

                    Geschmackssachen, über die sich hervorragend streiten lässt.

                    Freundliche Grüße

                    Vinzenz

                    1. Hallo,

                      Diese Schreibweise mag ich nicht, ich setze lieber immer Klammern. Andere lassen die Klammern immer weg, wenn sie nur können.

                      Geschmackssachen, über die sich hervorragend streiten lässt.

                      ... deshalb haben wir in der Firma dazu eine knallharte Ansage bekommen, wie das auszusehen hat. Am Anfang habe ich immer gemotzt. Aber irgendwann habe ich dann auch verstanden, dass erstens die einheitliche Schreibweise und zweitens der leicht abgewandelte PEAR-Stil sinnvoll für uns war. Das hat extrem viel Zeit gespart beim Pflegen und Fehlersuchen. Das bisschen Mehraufwand bei der Ersterfassung des Codes waren dagegen Peanuts. Und gelegntlich mel ein Zeilenumbruch extra odere eine Trennlinie (als Kommentar) macht Scripte lesbarer.

                      Wir hatten die Diskussion neulich aber schon mal. Da hatte jemand behauptet, dass er die kürzest mögliche Schreibweise für am Besten hielte. Ich musste da gewaltug grinsen, denn das habe ich auch mal. Immerhin zeichnet einen das als "Fachkraft" aus, wenn man so ein Gekritzel dann noch entschlüsseln kann *gg*.

                      In Wirklichkeit liegt in der Disziplin zur ausführlichen Schreibweise und guten Kommentaren die Fachkenntnis.

                      Dazu gehören Dinge, die einem beim Ersinnen der Scripte manchmal gar nicht in den Kopf kommen, aber spätestens, wenn man nach zwei Jahren die Elaborate lange verschollener Kollegen reparieren und erweitern soll, dann kommt die Erleuchtung!

                      LG
                      Chris

                      1. Hallo Chris,

                        Wir hatten die Diskussion neulich aber schon mal. Da hatte jemand behauptet, dass er die kürzest mögliche Schreibweise für am Besten hielte.

                        ich erinnere mich, was ich geschrieben habe, und offensichtlich hast du es gründlich missverstanden (schade, dass das Archiv 2006 noch nicht durchsuchbar ist, sonst hätte ich den Beitrag hier nochmal verlinkt).

                        Ich habe nicht gesagt, dass ich die kürzestmögliche Schreibweise für die beste halte, sondern die, die am wenigsten Überflüssiges enthält. Dabei ging es mir um die Formulierung eines Ausdrucks oder einer Anweisung, nicht um deren Formatierung im Quellcode. Ich befürworte ausdrücklich eine übersichtliche und konsequente Gliederung durch Einrückung und sauberes Untereinanderstellen von gleichartigen Teilausdrücken sowie eine günstig gesetzte Leerzeile zur optischen Auflockerung. Auch reichliche und informative Kommentare finde ich unbedingt ratsam. Was ich nicht mag, sind unbeholfen und dadurch unnötig kompliziert ausformulierte Anweisungen und Expressions.

                        Immerhin zeichnet einen das als "Fachkraft" aus, wenn man so ein Gekritzel dann noch entschlüsseln kann *gg*.

                        Danke, ich werd' mich bei Gelegenheit revanchieren. ;-)

                        In Wirklichkeit liegt in der Disziplin zur ausführlichen Schreibweise und guten Kommentaren die Fachkenntnis.

                        D'accord. Aber "ausführlich" != "umständlich".
                        Schönes Wochenende noch,

                        Martin

                        --
                        Frauen sind wie Elektrizität: Fasst man sie an, kriegt man eine gewischt.
                      2. Hallo Chris,

                        Wir hatten die Diskussion neulich aber schon mal. Da hatte jemand behauptet, dass er die kürzest mögliche Schreibweise für am Besten hielte. Ich musste da gewaltug grinsen, denn das habe ich auch mal. Immerhin zeichnet einen das als "Fachkraft" aus, wenn man so ein Gekritzel dann noch entschlüsseln kann *gg*.

                        Ach das erinnert mich an die Zeit, in der ich C erlernte. Etliche Unterrichtseinheiten ging es um das Auswerten von komplexen nicht geklammerten Ausdrücken. Das ist zwar einerseits hilfreich, wenn man mal sowas vor die Augen bekommt. Man erinnert sich daran, dass man dies mit Hilfe der Referenz auch wieder hinkriegt.

                        In Wirklichkeit liegt in der Disziplin zur ausführlichen Schreibweise und guten Kommentaren die Fachkenntnis.

                        Effizienter Code ist auch wartbarer Code. Als Beispiel bekamen wir unter anderem auch das in Assembler umgewandelte Ergebnis von unleserlichen Kompaktschreibweisen und hübsch auseinandergedröseltem Code zu sehen. Es war wirklich verblüffend: Das kompilierte Ergebnis war das Gleiche :-)

                        Viel wichtiger ist es, effiziente Algorithmen zu verwenden, siehe z.B. https://forum.selfhtml.org/?t=121373&m=780681. Dabei sollte man nicht aus den Augen verlieren, dass für Spezialfälle spezielle Algorithmen effizienter sein können als universelle Algorithmen. Man muss seine Aufgabenstellung mit Randbedingungen und Werkzeugen kennen. Wenn eine Optimierung nicht erforderlich ist, sollte man sie auch nicht vornehmen, der alte Grundsatz "Never touch a running system". [1]

                        Freundliche Grüße

                        Vinzenz

                        [1] Wobei heutzutage bei Sicherheitslücken leicht aus einem "running system" ein "dead system" oder schlimmer "zombie system" wird. D.h. in Sicherheitsfragen gilt eher, dass man jeden relevanten Sicherheitspatch installieren sollte.

                    2. Hi,

                      Der Submit-Button hat einen festgelegten Namen, daraus ergibt sich ein zugelassenenes Name-Value-Paar, das ich zwar zusätzlich berücksichtigen muss. Ein einziges Mal.

                      ein überflüssiges mal.

                      Vergleichbar vielleicht mit dem Weglassen von Blockklammern in Konstrukten wie

                      if (Bedingung)
                          Anweisung;
                        else
                          Anweisung;
                        Anweisung;

                      Diese Schreibweise mag ich nicht,

                      Ich auch nicht - allerdings mag ich auch keine überflüssigen Klammern.
                      In diesem Fall würde ich:
                        if (Bedingung) Anweisung;
                        else Anweisung;
                        Anweisung;
                      bevorzugen - unter der Voraussetzung, daß das in einer Zeile am Bildschirm dargestellt wird. Bei Zeilenumbrüchen finde ich Klammerungen dann doch übersichtlicher.

                      Aber ich habe ohnehin manchmal Probleme mit den Klammern und wundere mich schonmal über Fehler, die durch "{" bzw. ")" anstatt "}" auftreten. Sieht am Bildschirm einfach zu ähnlich aus.

                      freundliche Grüße
                      Ingo

                      1. Hallo Ingo,

                        Ich auch nicht - allerdings mag ich auch keine überflüssigen Klammern.

                        Ich habe keine überflüssigen Klammern, diese Klammern erleichtern _mir_ das Lesen und ermöglichen mir das Verstehen.

                        In diesem Fall würde ich:
                          if (Bedingung) Anweisung;
                          else Anweisung;
                          Anweisung;

                        diese Anweisung ist für _mich_ sehr schwer zu lesen, weil meine Augen automatisch die Klammern suchen, die die Blöcke begrenzen. Deswegen habe ich ein Problem, solche Anweisungen zu verstehen. Das ist mein persönlicher Geschmack. Andere dürfen dies gern anders halten.

                        Freundliche Grüße

                        Vinzenz

          2. Hallo,

            Frage: warum sollte man darauf zugreifen?

            Um z.B. mehrere Submitbuttons für unterschiedliche Aktionen ermöglich zu können... :-)

            m.E. ist das leider die einzige Möglichkeit dafür. Da aber der value-Wert gleich der Beschriftung sein muss, tauchen im Empfängerskript abfragen wie

              
              
            if ($_POST['action'] == "Vorschau") {  
              
            } elseif ($_POST['action'] == "speichern") {  
              
            }  
            
            

            welche mir gar nicht gefallen. Gibt es echt keine weiteren Möglichkeiten?

            werbeklaus

            1. Hallo,

              Frage: warum sollte man darauf zugreifen?

              Um z.B. mehrere Submitbuttons für unterschiedliche Aktionen ermöglich zu können... :-)

              m.E. ist das leider die einzige Möglichkeit dafür. Da aber der value-Wert gleich der Beschriftung sein muss, tauchen im Empfängerskript abfragen wie
              [code lang=php]

              if ($_POST['action'] == "Vorschau") {

              } elseif ($_POST['action'] == "speichern") {

              }

              Das ist mir sowieso anders eingebläut worden!

              Strikte namentlich Trennung von

              • Dialogfeldern mit Bindung (Daten, die 1:1 in die DB gehören)
              • Controls (Daten und Einstellungen, die erst interpretiert
                  werden müssen, um dann ggf. in die DB zu gelangen oder etwas
                  zu bewirken)
              • Steuerbuttons (Einfache Aktionselmente, die direkten Einfluss
                  auf den Steuerfluss haben dürfen)

              Und wenn man dann die "Array"-Eigenschaften von PHP nutzt:

              name="btn[preview]"
                name="btn[save]"

              name="data[vorname]"
                name="data[nachname]"

              name="ctrl[newsletter]"
                name="ctrl[gender]"

              Dann kann man ziemlich viel automatisieren im Script. Das finde ich ganz vorteilhaft.

              if(isset($_POST([btn['previev']))

              sollte dann die Entscheidung liefern können.
              Dann ist es auch egal, welche Sprachwe für die Anzeige eingestellt ist, für den Fall, dass Du mehrere vorgesehehen hast. Dein Label auf dem Button kann dann also lauten, wie es will.

              LG
              Chris

    2. Hallo Vinzenz,

      Bitte schaffe Dir eine neuere Quelle an, um PHP zu lernen. Bereits seit PHP 4.1.0 wird empfohlen, die neuen superglobalen Variablen zu nutzen.

      ist mir bekannt, und ich beherzige diese Empfehlung auch. Allerdings ist mir der Sinn dieser Umgruppierung bis jetzt noch nicht klargeworden. PHP stellt doch die gleichen Informationen zur Verfügung, nur eben auf anders benannte Objekte verteilt als bei den älteren Versionen.

      Auch warum diese Variablen als _super_global bezeichnet werden, ist mir schleierhaft. Was ist daran so super? Sie sind global und durch PHP vordefiniert, Punkt.
      Oder hast du da zufällig eine Erklärung?

      Schönes Wochenende noch,

      Martin

      --
      Wer morgens zerknittert aufsteht, hat den ganzen Tag Gelegenheit, sich zu entfalten.
      1. Hallo Martin,

        Auch warum diese Variablen als _super_global bezeichnet werden, ist mir schleierhaft. Was ist daran so super? Sie sind global und durch PHP vordefiniert, Punkt.
        Oder hast du da zufällig eine Erklärung?

        Bevor ich Dir das erklären muss, sollte Dir die PHP-Doku zum Geltungsbereich von Variablen ausreichen :-)

        Freundliche Grüße

        Vinzenz

        1. Hallo,

          Oder hast du da zufällig eine Erklärung?
          Bevor ich Dir das erklären muss, sollte Dir die PHP-Doku zum Geltungsbereich von Variablen ausreichen :-)

          Ja danke, das war tatsächlich sehr aufschlussreich.
          Denn die Tatsache, dass "normale" globale Variablen _nicht_ automatisch im Scope von untergeordneten Funktionen verfügbar sind (im Gegensatz z.B. zu JS und C), war mir bisher nicht bekannt.
          Wieder was dazugelernt, also hat sich die Frage doch schon gelohnt. :-)

          So long,

          Martin

          --
          Lieber eine Fliege im Porzellanladen
          als ein Elefant in der Suppe.
          1. Hallo Martin,

            Wieder was dazugelernt, also hat sich die Frage doch schon gelohnt. :-)

            frei nach O'Brian: "Heya, wir sind hier um zu lernen!"

            Freundliche Grüße

            Vinzenz

    3. Hallo Vinzenz,

      vielen Dank für deine Hinweise! Ich hatte ein Tutorial aus dem Internet verwendet wo kein Datum angegeben war. Offenbar war das aber ein sehr, sehr altes Tutorial... Ich werde mich wohl lieber nach einem neueren umsehen um solche Fehler zu vermeiden.

      Danke!

      Maxi

      1. Hallo Maxi,

        vielen Dank für deine Hinweise! Ich hatte ein Tutorial aus dem Internet verwendet wo kein Datum angegeben war. Offenbar war das aber ein sehr, sehr altes Tutorial... Ich werde mich wohl lieber nach einem neueren umsehen um solche Fehler zu vermeiden.

        Du kannst z.B. die Forumssuche nutzen. Mir hat sie auf die Schnelle, gefüttert mit
          category:PHP Tutorial
        u.a. diesen interessanten Thread ausgegeben: </archiv/2005/1/t98508/#m600562>.

        Dort solltest Du zielführende Tipps finden.

        Danke!

        Aber bitte, gern geschehen. Auf Deinem Weg kannst Du hier immer wieder gern reinschauen. Diejenigen, die Neues lernen wollen und dies auch zeigen, werden hier  gerne unterstützt.

        Freundliche Grüße

        Vinzenz