Thorsten: Auf existenz überprüfen Get Variable ?

Abfrage einer Variable die über GET übergeben wurde,
1. ob sie überhaupt da ist
2. ob sie das drin ist was drin sein soll

if((isset($_GET['aktion'])) AND($_GET['aktion']=='edit'))

Wäre das so OK.

Thorsten

  1. Abfrage einer Variable die über GET übergeben wurde,

    1. ob sie überhaupt da ist
    2. ob sie das drin ist was drin sein soll

    if((isset($_GET['aktion'])) AND($_GET['aktion']=='edit'))

    Wäre das so OK.

    Wo ist deine Frage? ôO

    Matze

    1. Wo ist deine Frage? ôO

      Ob die Abfrage so in Ordnung wäre, wenn also von einer Seite ein GET übermittelt wird muß erst abgfragt werden ob die var vorhanden ist und dann ob was drin steht, was drin sein soll.

      if((isset($_GET['aktion'])) AND($_GET['aktion']=='edit'))

      oder kann man es einfacher, sicherer, anders machen?

      Thorsten

      1. Hallo,

        Ob die Abfrage so in Ordnung wäre, wenn also von einer Seite ein GET übermittelt wird muß erst abgfragt werden ob die var vorhanden ist und dann ob was drin steht, was drin sein soll.

        if((isset($_GET['aktion'])) AND($_GET['aktion']=='edit'))

        genau so. statt AND kannst du && verwenden. wenn es länger wird auch in zwei Zeilen aufteilen

        if( isset($_GET['aktion'])  &&
           $_GET['aktion']=='edit') {
        }

        hast zudem zwei Klammerpaare zuviel

        Gruß

        jobo

        1. hast zudem zwei Klammerpaare zuviel

          Nicht zuviel, sondern mehr als nötig.

        2. Hi,

          wenn es länger wird auch in zwei Zeilen aufteilen

          if( isset($_GET['aktion'])  &&
             $_GET['aktion']=='edit') {
          }

          das Aufteilen komplexer Bedingungen auf zwei oder mehr Zeilen finde ich auch sehr empfehlenswert. Aber im Interesse der besseren Lesbarkeit würde ich empfehlen, den logischen Operator nicht ans Zeilenende zu schreiben, sondern an den Anfang der Folgezeile:

          if (isset($_GET['aktion'])
             && $_GET['aktion']=='edit')

          Das hat den Vorteil, dass jede Zeile genau einem Denkschritt entspricht:

          Bedingung 1 ...
             UND   Bedingung 2 ...
             UND   Bedingung 3

          Damit ist das Gefüge leichter zu erfassen und zu begreifen, finde ich.

          Ciao,
           Martin

          --
          Eine Neandertaler-Sippe sitzt in ihrer kalten Höhle. Seufzt der Stammesälteste: "Hoffentlich erfindet bald jemand das Feuer!"
          1. Hallo,

            ja, du hast recht:

            http://framework.zend.com/manual/de/coding-standard.coding-style.html#coding-standard.coding-style.control-statements

            ich versuch mich halt an den codingstandard des zend framework zu halten.

            darin u.a. auch:

              
            set_include_path(get_include_path() . PATH_SEPARATOR .  
                             $rootPath . '/application/config' . PATH_SEPARATOR .  
                             $rootPath . '/application/models' . PATH_SEPARATOR .  
                             $rootPath . '/library' . PATH_SEPARATOR .  
                             $rootPath . '/public');  
            
            

            Das Verknpüpfungszeichen in dem Fall aber am Ende. Dafür aber schön der "PATH_SEPARATOR".

            Sinnig auch der Hinweis, den closing Tag wegzulassen in Files, die keine Ausgabe machen (vermeidung von ungewolltem Whitespace). http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html

            Gruß

            jobo

            1. Hi,

              http://framework.zend.com/manual/de/coding-standard.coding-style.html#coding-standard.coding-style.control-statements
              darin u.a. auch:

              set_include_path(get_include_path() . PATH_SEPARATOR .

              $rootPath . '/application/config' . PATH_SEPARATOR .
                               $rootPath . '/application/models' . PATH_SEPARATOR .
                               $rootPath . '/library' . PATH_SEPARATOR .
                               $rootPath . '/public');

                
              damit widersprechen die ihrem eigenen Coding Style. Toll. ;-)  
                
              
              > Das Verknpüpfungszeichen in dem Fall aber am Ende.  
                
              Warum? Find' ich irgendwie ungünstig.  
              Noch viel schlimmer finde ich aber die öffnende Klammer am Zeilenende.  
                
              
              > Sinnig auch der Hinweis, den closing Tag wegzulassen in Files, die keine Ausgabe machen  
                
              Ja, das kann einem einige kurzweilige Stunden Debugging ersparen ...  
                
              So long,  
               Martin  
              
              -- 
              [why the heck](http://community.de.selfhtml.org/zitatesammlung/zitat175) do you jerk think, that wir ein doppelposting nicht bemerken, wenn you zwischendurch the sprache wechselst?  
                (wahsaga)  
              
              
              1. Hallo,

                damit widersprechen die ihrem eigenen Coding Style. Toll. ;-)

                Wie denn das?

                Das Verknpüpfungszeichen in dem Fall aber am Ende.

                Warum? Find' ich irgendwie ungünstig.

                Noch viel schlimmer finde ich aber die öffnende Klammer am Zeilenende.

                Wo war die jetzt?

                Gruß

                jobo

                1. n'Abend!

                  damit widersprechen die ihrem eigenen Coding Style. Toll. ;-)
                  Wie denn das?

                  In dem Abschnitt des Coding Style, den du verlinkt hast, steht folgendes Beispiel:

                  if (($a == $b)
                      && ($b == $c)
                      || (Foo::CONST == $d)
                  ) {
                      $a = $d;
                  }

                  Klarer Fall: Der Operator, der die Fortsetzung des Ausdrucks anzeigt, steht in der Folgezeile.

                  Noch viel schlimmer finde ich aber die öffnende Klammer am Zeilenende.
                  Wo war die jetzt?

                  Auch in dem zitierten Beispiel. Ein paar Zeilen über dem zitierten Ausschnitt noch deutlicher.

                  Ciao,
                   Martin

                  --
                  Der Sinn einer Behörde besteht in ihrer Existenz.
                    (alte Beamtenweisheit)
  2. hi,

    Wäre das so OK.

    isset() fragt ob eine Variable gesetzt ist, es ist so, dass PHP eine Notice oder Warnung zeigt, wenn Du einen Index abfragst, den es nicht gibt. Daher also vorher ein isset().

    Wenn isset() true meldet, kannst Du den index selbst abfragen, also ($_GET['indexbezeichner'])?

    Achtung: Wenn es den Index gibt, z.B. $_GET['vorname'], kann es immernoch sein, dass der String leer ist! Hierzu bediene Dich der Frunktion strlen().

    Beispiel zweier solcher if() Abfragen in einer Zeile:
    $ref = (isset($_GET['ref'])) ? (strlen($_GET['ref'])) ? $_GET['ref'] : 'noref' : '';

    Hotti

    --
    Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.
    1. Hi!

      Achtung: Wenn es den Index gibt, z.B. $_GET['vorname'], kann es immernoch sein, dass der String leer ist! Hierzu bediene Dich der Frunktion strlen().

      Wenn es ein Leerstring ist, dann ist es ein Leerstring. Den muss man nicht durch einen Leerstring ersetzen.

      Beispiel zweier solcher if() Abfragen in einer Zeile:
      $ref = (isset($_GET['ref'])) ? (strlen($_GET['ref'])) ? $_GET['ref'] : 'noref' : '';

      Abgesehen davon, dass der Trinitätsoperator keine if-Abfrage ist, gibt es die Funktion empty(), die wie isset() keine Notice-Meldung wirft, wenn sie mit nicht vorhandenem gefüttert wird.

      $ref = empty($_GET['ref']) ? 'noref' : $_GET['ref'];

      Weiterhin muss der Bedingungsausdruck nicht unbedingt geklammert werden. Klammern verdeutlichen zwar gelegentlich was gemeint ist, doch sollte man sie nur bei mehrteiligen Ausdrücken verwenden. Einteilige Ausdrücke zu klammern verringert nach meinem Dafürhalten die Lesbarkeit, besonders wenn im Ausdruck selbst auch noch Klammern auftauchen.

      Dein Beispiel sieht irgenwie seltsam aus. Wenn der GET-Parameter nicht vorhanden ist, gibst du einen Leerstring zurück, ist er aber vorhanden, jedoch "wertlos", gibst du ein noref zurück. Mein empty()-Beispiel setzt Nichtvorhandensein und Leerstring gleich (allerdings auch "0").

      Lo!