Perlentaucher: Frage zum Wiki-Artikel „Funktionen für Zeichenketten“

problematische Seite

Hallo!

Ich kopierte das Script vom Abschnitt "chr - Zeichen eines Zeichenwerts ermitteln" und fügte es im gedit (UTF8) ein. Ich rufe die Datei im Terminal auf und es wird eine Tabelle im HTML-Code ausgegeben. Bei der 13. Zelle "verschluckt" sich der Perl-Code. Es wird ein falscher HTML-Tag angegeben und statt einer 13 eine 3 (so </td>3= , statt <td>13 = </td>). Woran kann das liegen?

Hier der Fehler im ausgegebenen HTML-Code (gekürzt):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head><title>Test-Ausgabe</title></head>
<body>
<table border="1" bgcolor="#FFFFE0">
<tr>
<td>0 = </td>
<td>1 = </td>
<td>2 = </td>
<td>3 = </td>
<td>4 = </td>
<td>5 = </td>
<td>6 = </td>
<td>7 = </td>
</tr>
<tr>
<td>8 =</td>
<td>9 = 	</td>
<td>10 = 
</td>
<td>11 = 
         </td>
<td>12 = 
         </td>
</td>3 = 
<td>14 = </td>
<td>15 = </td>
</tr>

Vielen Dank!

  1. problematische Seite

    Hallo,

    Woran kann das liegen?

    Daran, dass du versuchst Steuerzeichen auszugeben. du könntest recherchieren, was dieses 13. Steuerzeichen tut. Ich tippe mal auf "Zeile löschen"

    Gruß
    Kalk

    1. problematische Seite

      Dankeschön! Auf so einen Gedanken wäre ich nie gekommen! Ich recherchierte und fand, dass das 13. Steuerzeichen ein CR ausgibt und dies gleichbedeutend für Wagenrückruf (\r) ist. Es gibt eine Menge Fallstricke für einen Laien, über die gestolpert werden kann.

  2. problematische Seite

    Na, Du hattest doch letztens die Referenzen am Wickel. Dann machen wir doch gleich einmal ein Beispiel für Modernes Perl und nehmen statt der umständlichen print()-Ausgabe doch gleich eine richtige Templating Engine:

    #!/usr/bin/perl
    
    use strict;
    use warnings;
    use HTML::Template;
    
    # Lese Handler DATA
    # übergebe Scalar Referenz
    my $data = do{ local $/ = undef; <DATA>  };
    
    # TE Instanz erstellen
    my $template = HTML::Template->new( scalarref => \$data );
    
    # Daten erzeugen
    my @slice = ();
    foreach my $num( 0..127 ){
        push @slice, {
            ord => $num,
            chr => chr($num)
        };
    }
    
    # Daten an TE Instanz übergeben
    # als Referenz auf das Array
    $template->param(chars => \@slice);
    
    # Template rendern und ausgeben
    print $template->output();
    
    # Template unterhalb DATA Token
    __DATA__
    
    <table>
        <thead>
            <tr>
                <th> ASCII Numerisch </th>
                <th> Zeichen </th>
            </tr>
        </thead>
        <tbody>
          <TMPL_LOOP name="chars">
            <tr>
                <td> <TMPL_VAR name="ord"> </td>
                <td> <TMPL_VAR name="chr"> </td>
            </tr>
          </TMPL_LOOP>
        </tbody>
    </table>
    
    

    Und das ist doch mal ein schönes Beispiel, wie man mit Perl einen ordentlichen Code schreiben kann.

    Machs besser 😉

    PS: Escapen nicht vergessen, das kann die TE, siehe untenstehend:

    <td> <TMPL_VAR name="chr" ESCAPE=HTML> </td>
    
    1. problematische Seite

      Hallo!

      Und das ist doch mal ein schönes Beispiel, wie man mit Perl einen ordentlichen Code schreiben kann.

      Ich wäre schon froh, eine Einkaufsliste schreiben zu können. Doch so ein Gedicht zu verstehen und selbst zu verfassen, sehe ich als hohe Kunst für Fortgeschrittene an.

      1. problematische Seite

        Ach das kann man alles lernen, Schritt für Schritt. Wichtig ist, den Sinn und Zweck zu erkennen, warum ein Template: Um Code und Layout sauber zu trennen.

        Und soo kompliziert ist mein Beispiel nun auch wieder nicht 😉

        PS: Das Markdown vom Forum hat einen Backslash gefressen. Hier isser nochmal nachgereicht:

        $template->param( chars => \\@slice );

        Indes: Übergeben wird ein Schlüssel und ein Wert. Und der Wert in einem Hash ist grundsätzlich immer ein Scalar. Also kann es nur eine Refernez sein, steht auch weiter oben im Kommentar.

        MfG

        1. problematische Seite

          Tach!

          Ach das kann man alles lernen, Schritt für Schritt. Wichtig ist, den Sinn und Zweck zu erkennen, warum ein Template: Um Code und Layout sauber zu trennen.

          Es gibt auch andere Vorgehensweisen, Programme zu strukturieren. Im obigen Fall wird die Trennlinie zwischen verschiedenen Sorten von Code gezogen, hier Perl und HTML. Nun ist es aber so, dass auch in der Ausgabe Logik benötigt wird, um bestimmte Bereiche in Abhängigkeit auszugeben oder nicht, oder Bereiche wiederholt darzustellen, oder auch nur, um zu kennzeichnen, dass da Variableninhalte ausgegeben werden sollen. Man löst das Problem hierbei, indem man eine dritte Sorte Code hinzunimmt: template-engine-spezifische Syntax. Und natürlich braucht man auch noch die Template-Engine, die das Template parsen muss, die zusätzlichen Syntaxelemente erkennen und entsprechenden Code ausführen muss, um die Ausgabe nach Wunsch zu erzeugen.

          Das Ziel, (Programm-)Code von Layout(-Code) zu trennen, ist auf diese Weise nicht erreichbar, wenn lediglich der eine Code (Template-Syntax) einen anderen Code (den der eigentlich verwendeten Programmiersprache) ersetzt. Im Prinzip ist es gar nicht erreichbar, solange irgendeine Art der Steuerung benötigt wird, um die Ausgabe zu erzeugen.

          Eine andere sehr übliche Herangehensweise ist, die Trennlinie zwischen der Geschäftslogik (das was das Programm hauptsächlich tun soll) und der Ausgabe zu ziehen. Für die Steuerung der Ausgabe verwendet man dann einfach eingebetteten Code derjenigen Programmiersprache, die man sowieso schon verwendet. Meist beschränkt sich die Ausgabelogik auf if-then-else, Schleifen, Variablenausgabe sowie Maskierungsfunktionen.

          Template-Engines mit eigener Syntax haben aber auch ihren Nutzen. Zum Beispiel dann, wenn die Templates von Personen ohne Programmierhintergrund erstellt werden sollen und sie lediglich die vereinfachte Syntax und die eingeschränkten Möglichkeiten der Template-Engine verwenden müssen. Im Prinzip bleibt es sich aber gleich, ob sie die drei Elemente in der einen Sprache oder der anderen erlernen müssen. Syntaktisch fehlerfrei müssen sie in jedem Fall arbeiten.

          dedlfix.

          1. problematische Seite

            Nun ist es aber so, dass auch in der Ausgabe Logik benötigt wird, um bestimmte Bereiche in Abhängigkeit auszugeben oder nicht, oder Bereiche wiederholt darzustellen, oder auch nur, um zu kennzeichnen, dass da Variableninhalte ausgegeben werden sollen. Man löst das Problem hierbei, indem man eine dritte Sorte Code hinzunimmt: template-engine-spezifische Syntax.

            Kann man. Es gibt aber auch andere Lösungen, das View umzuschalten. Wir haben das hier mal diskutiert vor vielen Jahren. Und selbstverständlich kann die hier gezeigte TE "bestimmte Bereiche wiederholt darstellen" man nennt das LOOP, siehe mein Beispiel. MfG

  3. problematische Seite

    Ergänzung:

    Der Artikel ist überarbeitungsbedürftig. Weil: Seit Version 5 unterstützt Perl Zeichenketten mit einer bestimmten Kodierung. D.h., vor der Anwendung von Funktionen die mit Zeichenketten zu tun haben, muss dem Interpreter mitgeteilt werden, dass er nicht byteorientiert sondern zeichenorientiert arbeiten soll und das mit einer bestimmten Kodierung die hierzu ebenfalls dem Interpreter mitzuteilen ist.

    Dem geschuldet ist seit Version 5.8 das Module Encode im Core jeder Distribution. Dieses Modul vermittelt zwischen Character- und Bytesemantic.

    MfG

    1. problematische Seite

      Hallo pl,

      Der Artikel ist überarbeitungsbedürftig. Weil: Seit Version 5 unterstützt Perl Zeichenketten mit einer bestimmten Kodierung.

      <I>

      Auf der ganzen Perlschiene wurde seit 2012 nichts gemacht. Und das war m.W. auch nur eine unveränderte Übernahme aus der Doku.

      Bis demnächst
      Matthias

      --
      Rosen sind rot.
      1. problematische Seite

        Auf der ganzen Perlschiene wurde seit 2012 nichts gemacht.

        Perl unterstützt Unicode seit dem Jahr 2001. Seit Version 5 im Jahr 2001 wurde die Unterstützung von Zeichenkodierungen kontinuierlich weiterentwickelt. Und mit v5.8 kam das Modul Encode in den Core, das war im Jahr 2010.

        Soweit zu Deinem Statement. MfG

        1. problematische Seite

          Hallo pl,

          Soweit zu Deinem Statement.

          Du hast sinnentstellend zitiert. Damit ist deine… „Kritik” völlig hinfällig.

          Wie auch immer, ich bin nach wie vor dafür, die Perl-Teile einfach zu löschen. Zu wenig Mehrwert, zu viel Arbeit das auf einen neuen Stand zu bringen. Und Perl ist de facto irrelevant für die Web-Entwicklung.

          LG,
          CK

          1. problematische Seite

            Hallo Christian Kruse,

            Wie auch immer, ich bin nach wie vor dafür, die Perl-Teile einfach zu löschen. Zu wenig Mehrwert, zu viel Arbeit das auf einen neuen Stand zu bringen. Und Perl ist de facto irrelevant für die Web-Entwicklung.

            Da sind wir schon mindestens zwei. Ein weiteres Argument wäre die Fokussierung auf die Kernthemen. Perl ist kein Kernthema.

            Bis demnächst
            Matthias

            --
            Rosen sind rot.
            1. problematische Seite

              Hallo Matthias,

              Perl ist kein Kernthema.

              Würde PHP als Kernthema gelten, wenn sich im Wiki etwas am entsprechenden Bereich täte (ich habe eine Menge Notizen in der digitalen Schublade liegen)? Den Fragen im Forum und der allgemeinen weiten Verbreitung nach ist PHP deutlich besser als weiteres Kernthema zusätzlich zu HTML, CSS, JavaScript und den allgemeinen Grundlagen qualifiziert als Perl.

              Gruß
              Julius

              --
              Verallgemeinerungen sind immer schlecht!
              1. problematische Seite

                Servus!

                Hallo Matthias,

                Perl ist kein Kernthema.

                Würde PHP als Kernthema gelten,

                Ja, wie Du schon schrubst, dreht sich im Forum viel um PHP.

                wenn sich im Wiki etwas am entsprechenden Bereich täte (ich habe eine Menge Notizen in der digitalen Schublade liegen)?

                Immer zu! Wir haben uns drauf geeinigt, keine Dokumentation anzustreben (die gibt's schon anderswo), sondern uns auf Tutorials und Anwendungsartikel zu konzentrieren.

                Herzliche Grüße

                Matthias Scharwies

                --
                Es gibt viel zu tun: ToDo-Liste
                1. problematische Seite

                  Hallo Matthias,

                  Wir haben uns drauf geeinigt, keine Dokumentation anzustreben (die gibt's schon anderswo)

                  Genau, da hatte ich schon mal mitbekommen (der als „problematische Seite“ verlinkte Perl-Artikel ist eine) und strebe ich nicht an.

                  sondern uns auf Tutorials und Anwendungsartikel zu konzentrieren.

                  Da will ich auch hin. Ich habe in an verschiedenen Stellen festgestellt, dass die PHP-Grundlagen-Vermittlung zu kurz kommt:

                  • im Includes-Tutorial wird erst lange erklärt, wie man feststellen kann, ob der Webspace PHP kann, das gehört imho in ein allgemeines Tutorial ausgelagert
                  • beim simplen Forum mit MySQL und PHP will ich objektorientiert arbeiten, dazu muss das irgendwo erklärt werden.
                  • in den im Wiki verlinkten Tutorials fehlen Hinweise auf Zeichenkodierung, sauberes HTML, Fehlerbehandlung und Sicherheit („das Beispiel ist sau unsicher, macht das nicht in der Praxis“ – wie man es bessser macht, fehlt dann meist)

                  Ich habe mir folgendes Vorgehen vorgenommen, um eine PHP-Einführung (analog zu dem HTML-Einstiegs-Tutorial) zu erstellen:

                  1. erster Abschnitt aus PHP/Tutorials/Dateien mittels include einbinden wird Teil des Abschnitts zum Aufsetzen und Testen der Arbeits- und Testumgebung.
                  2. PHP/Tutorials/Zusammenhang mit HTML und PHP/Tutorials/Kontrollstrukturen werden den nächsten Teil der Serie bilden, müssen ggf. noch überarbeitet bzw. homogenisiert werden
                  3. Ausbau der Serie

                  Dann kommen davon losgelöste einzelne Tutorials oder Artikel zu:

                  • Zeichenkodierung (Spielereien mit ord und chr, Multibyte-Funktionen wie mb_strlen(), Normalisierung)
                  • Datei-Upload (kompaktes Tutorial), Beschränkung auf Upload von Grafiken aus Gründen der Sicherheit
                  • Forum mit MySQL und PHP: Objektorientierte Programmierung, Rekursion vs. Iteration
                  • Datenspeicherung (Datei: JSON, CSV, serialisiert vs. Datenbank), häufig Thema im Forum!

                  Soweit zumindest der Plan...

                  Gruß
                  Julius

                  --
                  Verallgemeinerungen sind immer schlecht!
              2. problematische Seite

                Aloha ;)

                Würde PHP als Kernthema gelten, wenn sich im Wiki etwas am entsprechenden Bereich täte (ich habe eine Menge Notizen in der digitalen Schublade liegen)? Den Fragen im Forum und der allgemeinen weiten Verbreitung nach ist PHP deutlich besser als weiteres Kernthema zusätzlich zu HTML, CSS, JavaScript und den allgemeinen Grundlagen qualifiziert als Perl.

                Jein. Ja, PHP ist sehr wichtig. Ja, PHP könnte ein Kernthema werden. Wir müssen nur auch aufpassen, dass wir uns nicht verzetteln. Im Bereich PHP gibt es schon eine sehr gut gepflegte Dokumentation in deutscher Übersetzung, der wir egal wie - Manpower, qualitativ, Aktualität - nichts entgegenzusetzen haben.

                Selfhtml besetzt im Moment eine Nische, in der es wenig Konkurrenz gibt - als Webtech-Dokumentation in deutscher Sprache, die sich an Anfänger richtet. Hobby-Webseitenbastler zum Beispiel. Oder für Semi-Professionelle als Nachschlagwerk. In dieser Sparte haben wir nach wie vor Zugriffszahlen und eine große Relevanz - das ist der Grund, warum wir noch hier sind.

                Wir müssen uns ein Stück weit dessen auch bewusst sein, was wir für ein Publikum bedienen. Professionellere Anwender suchen längst nicht mehr bei uns nach Rat - die sind sehr viel näher an den Quellen unterwegs. Was ja auch klar ist - es sind Profis mit viel Vorahnung, die mit Englisch und/oder Fachsprache kein Problem haben.

                Ich finde es super, wenn Selfhtml weiter die Nische ausfüllt, die es ausfüllt. Zu dieser Nische gehört auch PHP. Ein wenig. In Form einzelner Tutorials oder einzelner How-To's in deutscher Sprache und an Anfänger gerichtet. Eine umfangreiche PHP-Sektion (wie wir sie für HTML/CSS/Javascript haben), die über diese Dinge hinausgeht, halte ich für Zielgruppen-verfehlt und unnötig - da gibt es php.net auf Deutsch und keinen Bedarf.

                Verstehen wir uns da bitte nicht falsch - ich finde es gut, wenn das Wiki und das Projekt wächst. Deshalb sind wir hier. Wir sind nur auch in der Situation, dass wir nicht gerade an Personalüberschuss leiden. Deshalb ist es manchmal sicher angebracht, sich vorher zu überlegen, wo man am sinnvollsten Arbeit investieren kann.

                Das war die nüchterne Analyse. Jetzt kommt die zweite Komponente: Wenns dein Steckenpferd sein soll und du da viel Lust drauf hast: Mach. Its a wiki. Und nichts ist stärker als intrinsische Motivation, ich will da niemanden ausbremsen 😉

                TL;DR: Es gibt Bedenken, aber nur auf rationaler / projekt-strategischer Seite. Grundsätzlich profitiert das Projekt von jeder Form von qualitativ hochwertigem und in sich schlüssigem Inhalt![1]

                Grüße,

                RIDER

                --
                Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[

                1. Nicht vergessen: Perl fliegt nicht vorrangig deshalb, weil es kein Kernthema ist, sondern weil der Perl-Bereich qualitativ nicht mehr mithalten kann - das Kernthema-Argument kommt erst dann zum Tragen, wenn es darum geht, ob man Kräfte mobil machen sollte um den Bereich zu sanieren, wenns keiner von sich aus tun will 😉 ↩︎

                1. problematische Seite

                  Hallo RIDER,

                  Jein. Ja, PHP ist sehr wichtig. Ja, PHP könnte ein Kernthema werden. Wir müssen nur auch aufpassen, dass wir uns nicht verzetteln. Im Bereich PHP gibt es schon eine sehr gut gepflegte Dokumentation in deutscher Übersetzung, der wir egal wie - Manpower, qualitativ, Aktualität - nichts entgegenzusetzen haben.

                  php.net will ich gar nicht nachbauen, eher das, was dort an Einsteiger-Freundlichen Informationen fehlt, nachreichen.

                  Selfhtml besetzt im Moment eine Nische, in der es wenig Konkurrenz gibt - als Webtech-Dokumentation in deutscher Sprache, die sich an Anfänger richtet.

                  In dieser Sparte haben wir nach wie vor Zugriffszahlen und eine große Relevanz - das ist der Grund, warum wir noch hier sind.

                  Und damit das auch so bleibt, halte ich etwas mehr Engagement im PHP-Bereich für nötig. Dort fehlen konsistente und (didaktisch und fachlich) hochwertige Beiträge für Einsteiger, wo ich hoffe, etwas leisten zu können.

                  Wir müssen uns ein Stück weit dessen auch bewusst sein, was wir für ein Publikum bedienen. Professionellere Anwender suchen längst nicht mehr bei uns nach Rat - die sind sehr viel näher an den Quellen unterwegs. Was ja auch klar ist - es sind Profis mit viel Vorahnung, die mit Englisch und/oder Fachsprache kein Problem haben.

                  Ich werde das so im Hinterkopf behalten und versuchen, wo immer möglich, Brücken zu den Quellen zu bauen. Für den Einsteig in ein bestimmtes, für den Betreffenden komplett neues Thema bzw. Themenbereich – da nehme ich mich nicht aus – ist eine Einführung in der Muttersprache oft einfacher als etwas in einer Fremdsprache. Alle Inhalte für Fortgeschrittene zu übersetzen, ist nicht leistbar und auch nicht nötig, weil irgendwann das Fachvokabular sitzt.

                  Ich finde es super, wenn Selfhtml weiter die Nische ausfüllt, die es ausfüllt. Zu dieser Nische gehört auch PHP. Ein wenig. In Form einzelner Tutorials oder einzelner How-To's in deutscher Sprache und an Anfänger gerichtet. Eine umfangreiche PHP-Sektion (wie wir sie für HTML/CSS/Javascript haben), die über diese Dinge hinausgeht, halte ich für Zielgruppen-verfehlt und unnötig - da gibt es php.net auf Deutsch und keinen Bedarf.

                  Ein Einstiegstutorial mit ein paar Ergänzungen wirds, keine Befehlsreferenz. Es geht mir auch darum, einen Weg aufzuzeigen, um PHP zu lernen. Vor allem sicher und dann Tipps zu geben, in welche Richtung man sich weiterentwickeln sollte und welche Möglichkeiten man hat (Objektorientierung, Unit-Tests).

                  Deshalb ist es manchmal sicher angebracht, sich vorher zu überlegen, wo man am sinnvollsten Arbeit investieren kann.

                  Meiner Meinung ist eine Investition in diesen Bereich durchaus sinnvoll, hier im Forum kommen oft grundlegende Fragen zu PHP bzw. Problembeschreibungen (Internationalisierung, Auslagern von Inhalten, Formulareingaben speichern, E-Mails versenden), die man in einem Tutorial über die Grundlagen von PHP abfrühstücken, oder die Grundlagen für eine Problemlösung zumindest im Wiki legen kann.

                  Grundsätzlich profitiert das Projekt von jeder Form von qualitativ hochwertigem und in sich schlüssigem Inhalt!

                  Die Schlüssigkeit ist im PHP-Bereich des Wikis bisher ein Problem, die vorhandenen Artikel sind nicht schlecht, aber ein ziemliches Durcheinander.

                  Nicht vergessen: Perl fliegt nicht vorrangig deshalb, weil es kein Kernthema ist, sondern weil der Perl-Bereich qualitativ nicht mehr mithalten kann

                  Beides hängt imho eng zusammen: Wäre Perl SELFHTML (bzw. im Web) genauso wichtig wie HTML, CSS und JavaScript, würde sich dessen schon jemand angenommen haben. Aber dass im Perl-Bereich in den letzten Jahren selbst kleinere Korrekturen von gelegentlich vorbei schauenden unterblieben, spricht für sich.

                  – das Kernthema-Argument kommt erst dann zum Tragen, wenn es darum geht, ob man Kräfte mobil machen sollte um den Bereich zu sanieren, wenns keiner von sich aus tun will 😉

                  Volle Zustimmung.

                  Gruß
                  Julius

                  --
                  Verallgemeinerungen sind immer schlecht!
          2. problematische Seite

            Aloha ;)

            Wie auch immer, ich bin nach wie vor dafür, die Perl-Teile einfach zu löschen. Zu wenig Mehrwert, zu viel Arbeit das auf einen neuen Stand zu bringen. Und Perl ist de facto irrelevant für die Web-Entwicklung.

            Meine Stimme hast du dafür nach wie vor.

            Auch wenn es mir für den Perlentaucher, der sich grade daran weiterbildet, natürlich leid tut, ihm seine Arbeitsgrundlage zu entziehen - aber unterm Strich ist er sicher besser beraten, sich das Wissen woanders anzueignen als bei uns in hoffnungslos veralteter Form.

            Das ist ja etwa so, wie wenn wir heutzutage ohne Hinweis auf dessen Überalterung ein HTML3.2-Tutorial bereitstellen würden als wenn das der Stand der Dinge wäre... Und genauso wie du sehe ich nach wie vor niemanden, der das verbessern kann - ich kann ja nichtmal Perl (und hab es auch nie vermisst) und vielen anderen potenziellen Autoren geht es sicher ähnlich.

            Grüße,

            RIDER

            --
            Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
            # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
            1. problematische Seite

              Hallo Camping_RIDER,

              Auch wenn es mir für den Perlentaucher, der sich grade daran weiterbildet, natürlich leid tut, ihm seine Arbeitsgrundlage zu entziehen -

              Wir könnten die Seiten ins Museum verschieben, mit einem Warnhinweis versehen und für die Bearbeitung sperren.

              Bis demnächst
              Matthias

              --
              Rosen sind rot.
              1. problematische Seite

                Servus!

                Hallo Camping_RIDER,

                Auch wenn es mir für den Perlentaucher, der sich grade daran weiterbildet, natürlich leid tut, ihm seine Arbeitsgrundlage zu entziehen -

                Wir könnten die Seiten ins Museum verschieben, mit einem Warnhinweis versehen und für die Bearbeitung sperren.

                Oder wie bei den Feature-Artikeln auf die entsprechenden Seiten auf webarchive.org verweisen:

                Herzliche Grüße

                Matthias Scharwies

                --
                Es gibt viel zu tun: ToDo-Liste
                1. problematische Seite

                  Hallo Matthias Scharwies,

                  Oder wie bei den Feature-Artikeln auf die entsprechenden Seiten auf webarchive.org verweisen:

                  Das ist in der Tat noch besser.

                  Bis demnächst
                  Matthias

                  --
                  Rosen sind rot.
                  1. problematische Seite

                    Hallo Matthias,

                    Oder wie bei den Feature-Artikeln auf die entsprechenden Seiten auf webarchive.org verweisen:

                    Das ist in der Tat noch besser.

                    Finde ich nicht. Wenn man sich auf fremde Plattformen verlässt, verliert man die Kontrolle über die eigenen Inhalte. Die Wayback-Maschine scheint gerade kaputt zu sein (Problem mit Mixed-Content) und hat außerdem nicht alle Seiten des alten sefhtml-Angebots gespeichert und verbockt die Zeichenkodierung. Beispiel: Astrid Steinmann: Ein Forum, ein Forum - ein Kφnigreich fόr ein Forum!

                    Das Schöne an archive.org ist natürlich, dass die dortigen Inhalte klar als archiviert und damit potenziell veraltet erkennbar sind. Ich finde es schade, wenn veraltete Inhalte nicht mehr verfügbar sind – Erschwert das Erforschen der Technik-Geschichte und das Wertschätzen der Gegenwart. Natürlich müssen Lernwillige auch davon abgehalten werden, diese veralteten Inhalte als aktuellen Stand der Dinge wahrzunehmen.

                    Gruß
                    Julius

                    --
                    Verallgemeinerungen sind immer schlecht!
                    1. problematische Seite

                      Servus!

                      Das stimmt auch alles!

                      Herzliche Grüße

                      Matthias Scharwies

                      --
                      Es gibt viel zu tun: ToDo-Liste
                    2. problematische Seite

                      Hallo Julius,

                      Wenn man sich auf fremde Plattformen verlässt, verliert man die Kontrolle über die eigenen Inhalte.

                      In dem Fall handelt es sich um eine Depublizierung. Wir wollen uns ja von diesen Inhalten distanzieren, bei uns soll es sie nicht mehr geben.

                      Bis demnächst
                      Matthias

                      --
                      Rosen sind rot.
                      1. problematische Seite

                        Hallo,

                        In dem Fall handelt es sich um eine Depublizierung. Wir wollen uns ja von diesen Inhalten distanzieren, bei uns soll es sie nicht mehr geben.

                        Statt zu depublizieren könnte man missionieren: Auf jeder Perl-Seite ein „So würde es in PHP aussehen“-Kästchen…

                        Gruß
                        Kalk

                        1. problematische Seite

                          Hallo Tabellenkalk,

                          In dem Fall handelt es sich um eine Depublizierung. Wir wollen uns ja von diesen Inhalten distanzieren, bei uns soll es sie nicht mehr geben.

                          Statt zu depublizieren könnte man missionieren:

                          None of our business. IMHO.

                          LG,
                          CK

                        2. problematische Seite

                          Hallo

                          Statt zu depublizieren könnte man missionieren: Auf jeder Perl-Seite ein „So würde es in PHP aussehen“-Kästchen…

                          Ich sehe, um bei deinem Bild zu bleiben, Religionskriege aufziehen.

                          Ein Python-Jünger — vielleicht war's auch ein Node-Adept — kommt daher, sieht das ‚„So würde es in PHP aussehen“-Kästchen‘ und wünscht das SelfHTML-Projektteam in in einen der tiefsten Schlünde der ewigen Vorhölle. Der neugewählte PHPapst hingegen verdammt in einer Erwiderung im schärfsten Ton der Empörung die Gesamtheit der Herätiker der Programmiererwelt. Zudem drückt er sein tiefstes Bedauern über das Hacksche Schisma aus.

                          Viel Spaß dabei. 😉

                          Tschö, Auge

                          --
                          Wenn man ausreichende Vorsichtsmaßnahmen trifft, muss man keine Vorsichtsmaßnahmen mehr treffen.
                          Toller Dampf voraus von Terry Pratchett
          3. problematische Seite

            Hallo,

            Du hast sinnentstellend zitiert.

            Für mich sieht es eher so aus, als ob pl die Aussage direkt auf Perl bezogen hat und nicht auf die Perl-„Dokumentation“ in unserem Wiki.

            Gruß
            Kalk

            1. problematische Seite

              Hallo

              Du hast sinnentstellend zitiert.

              Für mich sieht es eher so aus, als ob pl die Aussage direkt auf Perl bezogen hat und nicht auf die Perl-„Dokumentation“ in unserem Wiki.

              Meiner Meinung nach bezieht er sich auf den von Matthias genannten Zeitpunkt der Übertragung ins Wiki (2012) und darauf, dass wesentliche Änderungen an Perl schon lange vorher passiert sind, aber im SelfHTML-Wiki nicht berücksichtig werden. Das Weglassen des Teils von Mattias' Aussage, der besagt, dass es sich bei der Übertragung ins Wiki wohl nur eine Übernahme der bereits damals veralteten Inhalte der Doku handelte, ist mMn in der Tat sinnentstellend.

              Tschö, Auge

              --
              Wenn man ausreichende Vorsichtsmaßnahmen trifft, muss man keine Vorsichtsmaßnahmen mehr treffen.
              Toller Dampf voraus von Terry Pratchett
              1. problematische Seite

                Hallo,

                Ah, ok, das ist auch denkbar. Wieder mal ein schönes Beispiel dafür, dass Kommunikation Glücksache ist.

                Gruß
                Kalk