Benutzer Diskussion:Beatovich

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche
Hinweis:
Eine Diskussionsseite dient dazu, Änderungen am Artikel zu besprechen. Allerdings werden diese Seiten in unserem Wiki erfahrungsgemäß nur von sehr wenigen Leuten besucht.
  • Deshalb sollten Diskussionen über den Artikel zum Thema „Beatovich“ besser im SELFHTML-Forum geführt werden.
  • Unter https://forum.selfhtml.org/self/new kannst du einen entsprechenden Beitrag erstellen.
  • Bitte hinterlasse einen entsprechenden Link auf dieser Diskussionsseite, wenn du einen Thread im Forum eröffnet hast.

Namenskonventionen Beispiel:

Hallo beat, ich schlage folgende Konvention für die Bezeichnung der Dateien vor.

  • CSS_grundlagen_foo.html, sowohl für CSS2 und CSS3
  • CSS2_bar.html, Beispiele, die keine CSS3-Eigenschaften enthalten
  • CSS3_bat.html
  • CSS23_baz.html, Beispiele, die sowohl CSS2- als aus CSS3-Eigenschaften enthalten
  • HTML4_quz, Beispiele, die keine HTML5-Features enthalten
  • HTML5_foo

Denkbar wäre auch eine Ordnerstruktur

  • Beispiel:CSS-grundlagen/foo.html

Matthias 16:28, 3. Feb. 2011 (CET)--

Ein beginn mit CSS_grundlagen assoziiert ein Beispiel primär mit Doku:CSS/Grundlagen. Es sollte nichts mit einer CSS-Version zu tun haben.
sehe ich auch so. Deshalb z.B. CSS_grundlagen_attributselektor-teilübereinstimmungen.html genau wie CSS_grundlagen_id-selektor.html Matthias 19:38, 3. Feb. 2011 (CET)--
CSS_eigenschaften_box-shadow ist wohl klar, dass das sowieso nur in einer Version vorkommt.
Du präferierst also eine Struktur analog zur Doku.
* CSS_grundlagen_foo.html
* CSS_eigenschaften_foo.html
* CSS_praxis_bar.html
könnte ich auch mitgehen. Matthias 19:38, 3. Feb. 2011 (CET)--
In ganz anderen Sektionen (z.B. unter Artikel) gibt es z.B. HTML+CSS...
Beat 17:02, 3. Feb. 2011 (CET)
Wir sollten uns ziemlich am Anfang auf eine Systematik verständigen, solange die Beispiel-Anzahl noch übersichtlich ist. Matthias 19:38, 3. Feb. 2011 (CET)--
Ein Beispiel kann an vielen Orten referenziert werden. Der URI des Beispiels sollte zum Beispiel passen. Alles andere halte ich für sekundär.
Ich verstehe auch nicht, warum du einen Unterschied zwischen CSS1/2/3 machen willst. Als CSS Autor kann ich ja auch nicht definieren, welchen Standard der Browser anwenden soll.
Beat 19:52, 3. Feb. 2011 (CET)

Willkommen zurück

Schön wieder von dir zu lesen.

-- Matthias 13:06, 27. Nov. 2011 (CET) --

Ich will es nicht zu laut herausschreien. Ich habe ein wildes Jahr hinter mir, auch gesundheitlich, und das ist noch nicht zu Ende.
Beat 14:36, 27. Nov. 2011 (CET)

Perl Aktivität

Tach auch. Du hast da grad ein paar Code-Verbesserungen eingebracht. Leider sind einige davon Verschlimmbesserungen. Wenn Perl ein Webdokument erzeugt, muss es einen Content-Type-Header mitliefern. Die „or die()“s finden teilweise vor dessen Ausgabe statt, so dass noch nicht mal der Meldungstext beim Browser ankommt, sondern ein „Premature end of script headers“. Tatsächlich verhindert das jedoch die Zeile „use CGI::Carp qw(fatalsToBrowser);“. An anderen Stellen werden wegen des Abbruchs halbe Dokumente ausgeliefert. Vermutlich soll das nur ein Kompromiss sein. Du willst angedeuten, dass auf Fehler reagiert wird, aber da das nicht Thema des Beispiels ist, hast du es mit dem geringstmöglichen Aufwand mit „or die()“ realisiert. Die Erfahrung zeigt, dass Code oftmals kopiert wird und solche Debug-Hilfsmittel nicht durch was ordentliches ersetzt werden. Zudem sind Ausgaben von Fehlermeldungstext an unbekannte Anwender, wobei noch Systeminterna veröffentlich werden, alles andere als Best Practice. Ich weiß, wenn man es „richtig“ macht, dann bekommt man schnell mehr Code für Fehlerbehandlungen als den eigentlichen Anwendungsfall. Das macht Beispiele lang und unübersichtlich. Ich plädiere dafür, dass der auf Fehler testende Code so erstellt wird, wie man es „in echt“ machen würde, aber statt der eigentlichen Reaktion kann ruhig nur ein Kommentar stehen. Der Programmablauf sollte aber zu einem ordentlichen Ende führen. Gut wäre es auch, wenn die Beispiele mindestens nach dem EVA-Prinzip strukturiert wären (einige sind es). Im Pinzip muss nicht mal HTML ausgegeben werden. Plaintext, der lediglich das angestrebte Ergebnis zeigt, sollte auch reichen und das spart einige Zeilen, die für das zu verdeutlichende Thema nicht zum Kern gehören. – Da ich mich mit Perl aber nicht weiter auskenne, kann ich leider nur „meckern“ und es nicht selbst verbessern. --dedlfix 15:26, 27. Nov. 2011 (CET)

Meiner Meinung nach ist "use CGI::Carp qw(fatalsToBrowser);" nicht angebracht. Nicht einmal in der Entwicklungsumgebung. In einem Fehlerfall lässt sich ein halbfertiges HTML-Dokument schlicht nicht so reparieren, dass der Fehler lesbar bleibt.
Fehler aller Art gehören in eine extra Ressource geschrieben.
Ich halte das "open() or die" für das geringere Übel in den Beispielen.
An den Beispielen gäbe es ganz anderes zu bemängeln. Was tut all das HTML in den Codebeispielen? Nicht nur eine EVA-Angelegenheit. Es lenkt schlicht vom wichtigen ab, bläht die Beispiele auf und raubt den Platz für wichtigeres.

Bezüglich EVA habe ich hier mal ein alternatives Beispiel http://wiki.selfhtml.org/wiki/Doku_Diskussion:Perl/Funktionen_f%C3%BCr_Datum_und_Uhrzeit Beat 16:40, 27. Nov. 2011 (CET)

Da hab ich wohl offene Türen eingerannt. Ich sehe, dir ist das Problem bewusst und kann dich nur ermutigen, da etwas aufzuräumen. Die Beispiele sind ja recht allgemein und wenig webspezifisch, so dass es meiner Meinung nach auch reicht, Kommandozeilenprogramme draus zu machen. --dedlfix 18:29, 27. Nov. 2011 (CET)

Wenn ich mir manche Perl Beispiele anschaue, habe ich den Eindruck, die Autoren hatten mehr Fun an einem lustigen Beispiel, statt an einem lehrreichen Beispiel. Zudem kommen mir manche Erklärungen überflüssig akribisch vor und stehen eher im Weg. Dem Leser darf der Blick in den Code nicht verstellt werden.

Des weiteren sehe ich Bedarf für eine Spezialsektion, bzw. Erweiterung der Sektion CGI, um die Besonderheiten von HTML in Perl zu behandeln. Insbesondere:

  • Fehlerbehandlung auf Webservern / Server-Umgebungen.
  • Rudimentäre CGI-Anwendung inklusive Cookie-Management.

--Beat 13:46, 29. Nov. 2011 (CET)