heintzi: Parse error: parse error, unexpected $end on line 40

Hi zusammen, ich finde einfach diesen sch...Fehler nicht.
Kann mal bitte einer drüberschauen?
danke...

<? if(count($this->errs)>0):?>
 <b>Es sind Fehler aufgetreten:</b><br /><br />
 <? foreach($this->errs as $error): ?>
  - <?=$error?>
 <? endforeach; ?>
 <? return; ?>
<? endif;?>

<div style="padding: 7px;">
        <table width="100%">
          <? foreach($this->links as $key => $link): ?>
          <tr>
            <? if ($link['category']=='') : ?>
            <td style="width:15px;height:10px;background:#FFFFFF;"></td>
   <td align="left" style="padding-left:10px">
            <?=$link['category']?>
            </td>
             <? else :?>
            <td style="width:15px;height:10px;background:#FFAA00;"></td>
   <td align="left" style="padding-left:10px;font-size:14px;">
            <?=$link['category']?>
    </td>
            <? endif;?>
             </tr>
             <tr>
             <td colspan="2" style="padding-left:30px"><a href="http://<?=$link['link']?>"><?=$link['name']?></a></td>
            <td></td>
          </tr>
    </table>
    </div>

<div style="border-bottom: 1px dotted rgb(191, 191, 191); height: 4px; font-size: 4px;">
    </div>

<div style="padding-top:14px">Letzte Aktualisierung: <?=strftime("%d.%m.%Y %H:%M")?> Uhr.</div>
</div>

  1. Hallo

    Hi zusammen, ich finde einfach diesen sch...Fehler nicht.

    sich auf short_open_tags zu verlassen, ist meiner Meinung nach eine schlechte Idee. Dein Codeausschnitt passt nicht zur Fehlermeldung, da er keine 40 Zeilen enthält und $end darin nicht vorkommt.

    Freundliche Grüße

    Vinzenz

    1. echo $begrüßung;

      Dein Codeausschnitt passt nicht zur Fehlermeldung, da er keine 40 Zeilen enthält und $end darin nicht vorkommt.

      Das $end in der Meldung bezieht sich nicht aus eine Variable namens $end sondern auf das Ende der Datei. Eine unerwartete Variable wird mit "unexpected T_VARIABLE" gemeldet.

      echo "$verabschiedung $name";

    2. Hallo Vinzenz,

      sich auf short_open_tags zu verlassen, ist meiner Meinung nach eine schlechte Idee.

      da stimme ich dir uneingeschränkt zu.

      Dein Codeausschnitt passt nicht zur Fehlermeldung, da er keine 40 Zeilen enthält und $end darin nicht vorkommt.

      Da allerdings nicht. Wenn wir mal annehmen, dass am Dateiende vielleicht noch zwei Leerzeilen kommen, passt es nämlich mit den 40 Zeilen, und mit dem Unexpected $end will uns der Parser sagen, dass er das Dateiende ($end) erreicht hat, ihm aber zum syntaktischen Glück noch ein endforeach fehlt.

      Wobei ich die Notation der Strukturanweisungen mit dem Doppelpunkt und dem später folgenden end* reichlich gewöhnungsbedürftig finde. Ich habe sie, außer als Beispiel im Handbuch, noch nirgends vorher gesehen.

      So long,
       Martin

      --
      Ungeschehene Ereignisse können einen katastrophalen Mangel an Folgen nach sich ziehen.
        (Unbekannter Politiker)
      1. echo $begrüßung;

        Wobei ich die Notation der Strukturanweisungen mit dem Doppelpunkt und dem später folgenden end* reichlich gewöhnungsbedürftig finde. Ich habe sie, außer als Beispiel im Handbuch, noch nirgends vorher gesehen.

        Ja, sehr verbreitet ist das nicht, doch wenn man PHP so einsetzt, wie es gedacht ist, es also in das HTML einbettet und nicht tausend echos in PHP einbettet, dann finde ich diese Schreibweise

        <ul>
          <?php foreach ($liste as $element): ?>
            <li><?php echo htmlspecialchars($element) ?></li>
          <?php endforeach ?>
          </ul>

        besser als diese

        <ul>
          <?php foreach ($liste as $element) { ?>
            <li><?php echo htmlspecialchars($element) ?></li>
          <?php } ?>
          </ul>

        oder gar diese

        <ul>
          <?php foreach ($liste as $element)
                { ?>
                  <li><?php echo htmlspecialchars($element) ?></li>
          <?php } ?>
          </ul>

        Ich finde, dass aufgrund der zur normalen Schreibweise eines foreach

        foreach (...) {
            ...
          }

        meinetwegen auch

        foreach (...)
          {
            ...
          }

        hinzukommenden Codeelemente (<?php und ?>) das endforeach auffälliger zum foreach zugehörig zu sehen ist als die }-Klammer.

        Wer jetzt denkt: Allerorten wird doch gepredigt, PHP und HTML strikt zu trennen. Ja. Nein. Das kann nicht das Hauptziel sein. Besser ist eine Strukturierung nach Aufgabenbereichen; eine Trennung der Codeteile gemäß EVA-Prinzip. So vorgegangen ist das HTML-PHP-Gemisch allein im Ausgabeteil zu finden und kann durch überlegte Notierweise auch recht übersichtlich gehalten werden.

        echo "$verabschiedung $name";

  2. sieht ja aus, dass der sau graust :)

    verlasse dich nicht auf das vorhanden sein von short_open_tags
    http://at.php.net/ini.core

    nutze die macht von echo und verlasse dich auch hier nicht auf das vorhanden sein von short_open_tags
    http://at.php.net/echo

    verwende c-ähnliche syntax bei kontrollstrukturen (schleifen, verzweigungen)
    http://at.php.net/if
    wenn du das hier beachtest, und einen editor mit klammerhervorhebung besitzt, solltest du deinen fehler finden ;) - die wurzel des übels scheint in zeile 12 zu liegen

    entscheide dich für hexadezimale oder dezimale farbdarstellung bei css deklarationen

    lagere das css aus

    missbrauche keine tabellen zum layouten

    1. foreach nicht geschlossen oder was meinste?
      das script lief und ganz plötzlich abgeschmiert nach irgendeiner kleiner Layout-Änderung.
      kann bloß nicht mehr nachvollziehen was da war...

      grüzi

      1. foreach nicht geschlossen oder was meinste?

        in deinem code hört das zweite foreach jedenfalls nicht wieder auf

        wie gesagt: schreib deinen code ordentlich, das ist bei der von dir geposteten menge vertretbar und in ein paar minuten erledigt

        rücke ihn sauber ein und verwende die empfohlenen schreibweisen - natürlich gibt es berechtigung für alternative syntax, sie sich nicht sonderlich praktikabel in deinem fall nur sehr schwer lesbar

        1. Hello,

          rücke ihn sauber ein und verwende die empfohlenen schreibweisen - natürlich gibt es berechtigung für alternative syntax, sie sich nicht sonderlich praktikabel in deinem fall nur sehr schwer lesbar

          Und schon möchte ich wieder Werbung für den Allman-Style machen.
          Er sit nachgewiesenermaßen für Anfänger der beste Stil und hat in Tests an diversen Unis auch bei Fortgeschrittenen zu den geringsten Fehlerquoten geführt.

          http://de.wikipedia.org/wiki/Einrückungsstil

          Ich kann das auch aus eigener Erfahrung in unseren Teams bestätigen.

          Ein harzliches Glückauf

          Tom vom Berg

          --
          Nur selber lernen macht schlau
          http://bergpost.annerschbarrich.de
          1. Ich kann das auch aus eigener Erfahrung in unseren Teams bestätigen.

            ich bevorzuge 1TBS, allerdings mit tabulator-einrückung (für kontrollstrukturen), da sich so der entwickler die einrückungstiefe selbst zurechtlegen kann

            1. Hello,

              ich bevorzuge 1TBS, allerdings mit tabulator-einrückung (für kontrollstrukturen), da sich so der entwickler die einrückungstiefe selbst zurechtlegen kann

              Kannst Du das auch irgendwie begründen, warum Du diesen unübersichtlichen Stil bevorzugst?

              Ein harzliches Glückauf

              Tom vom Berg

              --
              Nur selber lernen macht schlau
              http://bergpost.annerschbarrich.de
              1. Kannst Du das auch irgendwie begründen, warum Du diesen unübersichtlichen Stil bevorzugst?

                ich finde es logischer (oder schöner), wenn die öffnende klammer einer funktion direkt dran klebt - auch bei css-files ist das praktisch - siehe folgende beispiele - ich bevorzuge die ersten beiden schreibweisen

                zur not kann ich mit allman-style auch leben - aber whitesmith oder gnu/emacs/fsf finde ich sehr unübersichtlich

                ein grund dafür mag vielleicht sein, dass der allman-style mit vbscript zb garnicht umsetzbar ist, weil es keinen klammern für kontrollstrukturen gibt - wenn man die selbe logik beim programmieren in c-ähnliche syntax überträgt, kommt man bei selber zeilen-zahl nun mal mit 1tbs am besten zurecht ;)

                unübersichtlich ist also relativ ;)

                  
                selektor {  
                  property: value;  
                }  
                  
                selektor { property: value; }  
                  
                selektor  
                {  
                  property: value;  
                }  
                  
                selektor {  
                  property: value;  
                         }  
                
                
        2. jau. das wars auch...
          zum teil ejdenfalls.
          der rest war die Anbindung zum Template drumherum;-(

          Danke!