nix: Frage zum Wiki-Artikel „Dateien_mit_include_nachladen“

problematische Seite

„… den (weitgehend) unsichtbaren Angaben des head und dem footer“? Daß mir

<html>
    <head> … </head>
    <body> … </body>
    <footer> … </footer>
</html>

entgangen ist, glaube ich eigentlich nicht. Da hat sich doch was verlaufen, oder? Sicher, so ein <footer> wird schon gerne mal halbwegs versteckt. Aber …

  1. problematische Seite

    Hallo nix,

    aufgepasst im Kasus-Dschungel! Im Wiki steht:

    Aber auch das HTML-Markup besteht einerseits aus dem Grundgerüst, den (weitgehend) unsichtbaren Angaben des head und dem footer, andererseits aus Navigation und Inhaltsbereich.

    Ich weiß, dass der VRG[1] einen schweren Stand hat, aber hier ist der Unterschied wirklich wichtig. "Dem Footer", das ist ein Dativ. Wäre der Footer eine weitgehend unsichtbare Angabe, wie der head, dann müsste er, wie der head, im Genitiv stehen. Tut er aber nicht.

    Deswegen besteht das "einerseits" nicht aus zwei, sondern aus drei Teilen und der Footer ist nicht unsichtbar.

    Ich gebe zu, dass man sich Dativ da tief konzentrieren muss, um das nicht verzuwechseln. Die Formulierung ist im Wiki jetzt etwas anders.

    Rolf

    --
    sumpsi - posui - obstruxi

    1. Verein zur Rettung von dem Genitiv ↩︎

    1. problematische Seite

      Oh, Robin Hopp, der Becher … Kutscher! 😆

  2. problematische Seite

    Es gibt da so zwei Unschönheiten:

    1.)

    <link rel="stylesheet" href=".source/main.css" />
    

    Sollte die Datei „main.css“ wirklich in einem verstecktem Ordner („.source“) liegen oder war doch

    <link rel="stylesheet" href="/source/main.css" />
    

    gemeint?

    2.) Hm. Das Folgende mag jetzt kleinlich wirken:

    <?php
    $today = date('d.m.Y');
    $now = date('H:i:s'); ?>
    

    … ergibt ein „Problem“ wenn der Abruf um die Millionstel-Sekunden um 00:00.000000 herum erfolgt:

    <p>Seite abgerufen am <?=$today?> um <?=$now?> Uhr.</p>
    

    Da könnte das Datum vom ersten Tag und die Uhrzeit vom folgenden Tag aufscheinen, was zu Verwirrung führt. Häufig(sic!) will man den Zeitpunkt des Seitenaufrufs ja gerade aus rechtlichen Gründen in der Seite dokumentieren (Bildschirmfotos, Ausdrucke) - und so könnte es um fast (scheinbar: „genau“) 24 Stunden versetzte Zeitangaben geben. Aus dem gleichen Grund - Eindeutigkeit - sollte man die Zeitzone angeben.

    Der mehrfache Aufruf von date(), das notlos wirkende Zwischenspeichern in Variablen und die sodann nicht perfekte Ausgabe (je nach Ansicht oder Umständen fehlt da jeweils ein htmlspecialchars()) ließen sich vermeiden:

    <p>Seite abgerufen am <?=date('d.m.Y \u\m H:i:s \U\h\r (T)');?></p>
    

    Alternative:

    <?php
    $today = date( 'd.m.Y', $_SERVER['REQUEST_TIME'] );
    $now   = date( 'H:i:s', $_SERVER['REQUEST_TIME'] );
    ?>
    

    und im include (weil an dieser Stelle auf Grund „verteilten Programmierens“ womöglich nicht erweislich nur das vom für diesen zuständigen „Webdesigner“ erwartete in den Variablen steht...)

    <p>Seite abgerufen am <?=htmlspecialchars( $today );?>
    um <?=htmlspecialchars( $now );?>
    Uhr (<?=ini_get( 'date.timezone' );?>).</p>
    
    1. problematische Seite

      Hallo Raketenwilli,

      der Typo bei der URL ist gefixt. Das darfst Du übrigens auch selbst; deinen alten User gibt's noch, auch wenn der behauptet, verlassen zu sein 😉

      Der mehrfache Aufruf von date(), das notlos wirkende Zwischenspeichern in Variablen und die sodann nicht perfekte Ausgabe (je nach Ansicht oder Umständen fehlt da jeweils ein htmlspecialchars()) ließen sich vermeiden:

      htmlspecialchars() brauch ich nur bei Daten zweifelhafter Herkunft, oder bei Daten, bei denen ich mit speziellen HTML Zeichen rechnen muss (< > &). Die Ausgabe von date() sollte beide Kriterien nicht erfüllen.

      $today = date('d.m.Y');
      $now = date('H:i:s'); 
      

      ist dagegen defekt, da hast Du recht. Nicht, was die Variablen angeht. Es ist für Anfänger vorteilhaft, finde ich, Daten in Variablen zwischenzuparken, so dass der Wert einen Namen hat.

      Den Umstand, dass zwei verschiedene Timestamps formatiert werden, löst man entweder wie von Dir gezeigt durch einen einzigen date()-Aufruf, oder so:

      $systemZeit = new DateTimeImmutable("now");
      $datum = $systemZeit->format("d.m.Y");
      $uhrzeit = $systemZeit->format("h:i:s");
      

      oder ohne Klasse:

      $systemZeit = time();
      $datum = date("d.m.Y", $systemZeit);
      $uhrzeit = date("h:i:s", $systemZeit);
      

      natürlich immer vorausgesetzt, dass die Timezone des Servers passt.

      Im Artikel habe ich jetzt deinen Vorschlag mit REQUEST_TIME eingebaut und die Zwischenvariablen nun doch entfernt. Das potenzielle Problem ist in eine Anmerkung verschoben. Sonst hängt man die Leser, die sich einfach diese Technik abschauen wollen, nur ab.

      Rolf

      --
      sumpsi - posui - obstruxi
      1. problematische Seite

        Hallo

        htmlspecialchars() brauch ich nur bei Daten zweifelhafter Herkunft, oder bei Daten, bei denen ich mit speziellen HTML Zeichen rechnen muss (< > &). Die Ausgabe von date() sollte beide Kriterien nicht erfüllen.

        htmlspecialchars brauchst du jedesmal, wenn der Kontext einer Ausgabe hin zu HTML wechselt. Davon auszugehen, dass (zum Beispiel) der Rückgabewert einer Funktion „ungefährlich“ ist, ist optimistisch. Normalerweise ist die Rückgabe von date ungefährlich, aber Pferde und Apotheken und so. Das kann Sauereien geben, die man nicht aufwischen müssen will.

        Tschö, Auge

        --
        „Habe ich mir das nur eingebildet, oder kann der kleine Hund wirklich sprechen?“ fragte Schnapper. „Er behauptet, nicht dazu imstande zu sein“ erwiderte Victor. Schnapper zögerte (…) „Nun …“ sagte er schließlich, „ich schätze, er muss es am besten wissen.“ Terry Prattchett, Voll im Bilde
        1. problematische Seite

          Beispiel:

          <?=date('\<\h\1\>\H\a\l\l\o \W\e\l\t\!\<\/\h\1\>');?>
          

          → → →

          <h1>Hallo Welt!</h1>
          

          aber sowas ist „sehr speziell“. Immer dann, wenn der Progger das erste Argument von date() (also das Format) „voll im Griff“ hat ist es tatsächlich „eher harmlos“. Insoweit sind Rolfs Änderungen O.K.

          1. problematische Seite

            Hallo Raketenwilli,

            ja, ich bin irgendwie davon ausgegangen, dass ein Programmierer weiß, was die von ihm genutzten Funktionen tun.

            Es ist natürlich ein zweischneidiges Schwert. Wenn man sich angewöhnt, JEDE Ausgabe durch htmlspecialchars zu nudeln, vergisst man es auch nicht versehentlich.

            Rolf

            --
            sumpsi - posui - obstruxi
      2. problematische Seite

        Hallo Raketenwilli,

        der Typo bei der URL ist gefixt. Das darfst Du übrigens auch selbst; deinen alten User gibt's noch, auch wenn der behauptet, verlassen zu sein 😉

        Ha. Bin grad drauf gestoßen und hab sogar das Passwort „erinnert“.

        Ergo: „THX“ für den Hinweis.

    2. problematische Seite

      Wegen dem, was danach noch kommt (von wegen „jedes Mal“ und so): Grüße von Simonyi bzw. einem, der trotz seiner damaligen Umgebung das was verstanden hat — und hier, thematisch, nebendran paßt.

      1. problematische Seite

        Kann’s mir nicht verkneifen. Daß „Simonyi lebt“. Beispiel gefällig?

        „NSApplicationMain Apply this attribute to a class to indicate … NSApplicationMain(CommandLine.argc, CommandLine.unsafeArgv)“

        Auszug aus The Swift Programming Language (Swift 5.7) Apple Inc. https://books.apple.com/de/book/the-swift-programming-language-swift-5-7/id881256329 Dieses Material ist möglicherweise urheberrechtlich geschützt.

        (BTW: ja, die Quell-Angabe ist auch, ganz automatisch beim C&P, mitzitiert worden. Also laß’ ich die mal so stehen.)