(PHP) XML-Ersetzungen, Bewertung einer Klasse

[Julian von Mendel]

Hallo Welt, hallo Forum,

ich habe eine Klasse geschrieben und dokumentiert. Mir fallen noch diverse Features ein, die ich gerne implementieren möchte, vorher würde ich jedoch gerne erfahren, was ihr von dem Konzept an sich und den überschaubaren Erweiterungen bis jetzt haltet, um ggf. größere Probleme vorher noch korrigieren zu können. Meine XML-Klasse
Wer Fehler im PHP-Code findet, Rechtschreibfehler ausfindig macht, Verbesserungsideen für das Konzept oder den Code hat ist herzlich dazu eingeladen, mir eine Antwort zu schreiben :)
(Die Website auf der das steht ist noch nicht ganz online, sie ist als Ersatz für meine jetzige Internetseite gedacht. Ich nehme auch Verbesserungsvorschläge für die Website selbst an.)

Schöne Grüße
Julian

[dedlfix]

echo $begrüßung;

Wer Fehler im PHP-Code findet, Rechtschreibfehler ausfindig macht, Verbesserungsideen für das Konzept oder den Code hat ist herzlich dazu eingeladen, mir eine Antwort zu schreiben :)

Vorab: Intensiv werde ich mich wohl nicht damit beschäftigen, da ich keinen Leidensdruck habe, sie einsetzen zu wollen/müssen. :-) Aber was mir so bei Drüberfliegen aufgefallen ist:

Wenn du Quellcode durch Einrückungen formatierst, und dann auch noch Leerzeichen einfügst, dass bestimmte Dinge untereinander stehen (in meinen Augen unnötiger Aufwand / Mikrooptimierung) solltest du bei der Ausgabe auf der Weseite eine diktengleiche Schriftart verwenden, sonst geht der Effekt verloren.

Konstante Stringwerte, vor allem wenn sie als Parameter übergeben werden sollen, könnten als (Klassen-)Konstanten hinzugefügt werden. Codevervollständiger können Tipparbeit bei Konstanten abnehmen, aber nicht bei Strings.

XML verlangt geringfügig andere Maskierungen als htmlspecialchars in der Grundeinstellung berücksichtigt (')

Der Code glänzt durch die Abwesenheit jeglicher erläuternder Kommentare. Die Absicht hinter einen bestimmten Codeteil anzuführen ist dabei hilfreicher als triviale Beschreibungen dessen was eh aus dem Quelltext zu lesen ist. Eine (manchmal ungewünschte) Fähigkeit des menschlichen Gehirns ist, Dinge vergessen zu können. Das wird dir auch passieren, und dann stehst du eines Tages da und analysierst deinen eigenen Code, um herauszufinden, waszumgeier du dir damals dabei gedacht hast. :-) Empfehlenswert ist auch das Verwenden von PHPDoc-Kommentarblöcken. Anwender mit IDEs, die diese Blöcke auswerten können werden es dir danken.

Da gibt es irgendwo ein Beispiel in dem du erst das error_reporting auf E_ALL stellt und dann die Ausgabe pufferst, um sie mit der Klasse weiterzubearbeiten. Ich denke nicht, dass das Weiterverarbeiten der Fehlermeldungstexte gewünscht und sinnvoll ist.

Callbacks kann man vor dem Aufruf und auch schon beim Entgegennehmen mit is_callable() auf Ausführbarkeit testen.

echo "$verabschiedung $name";

[Julian von Mendel]

Hi,

danke für deine zahlreichen Ratschläge zum Programmcode. Ich werde sie mir der Reihe nach vornehmen.
Warum würdest du sie nicht einsetzen wollen? Findest du sie nutzlos, blöd oder brauchst du sie nur nicht?

Schöne Grüße
Julian

[dedlfix]

echo $begrüßung;

Warum würdest du sie nicht einsetzen wollen? Findest du sie nutzlos, blöd oder brauchst du sie nur nicht?

Letzteres, jedenfalls zur Zeit nicht.

echo "$verabschiedung $name";

[Julian von Mendel]

Hi,

Da gibt es irgendwo ein Beispiel in dem du erst das error_reporting auf E_ALL stellt und dann die Ausgabe pufferst, um sie mit der Klasse weiterzubearbeiten. Ich denke nicht, dass das Weiterverarbeiten der Fehlermeldungstexte gewünscht und sinnvoll ist.

stimmt. Was für ein Vorgehen schlägst du alternativ vor? (Ist nur im Beispiel so. Für mich selbst habe ich eine Funktion definiert, die die Fehlermeldungen abfängt und gleich ausgibt. Soll ich das auch so ins Beispiel übernehmen?)

Mein Programmcode braucht keine Kommentare, der dokumentiert sich selbst *g*.

Schöne Grüße
Julian

[dedlfix]

echo $begrüßung;

Da gibt es irgendwo ein Beispiel in dem du erst das error_reporting auf E_ALL stellt und dann die Ausgabe pufferst, um sie mit der Klasse weiterzubearbeiten.
Was für ein Vorgehen schlägst du alternativ vor? (Ist nur im Beispiel so. Für mich selbst habe ich eine Funktion definiert, die die Fehlermeldungen abfängt und gleich ausgibt. Soll ich das auch so ins Beispiel übernehmen?)

Nein. Im Prinzip ist das nicht die Aufgabe deiner Klasse, die Fehler des Anwenders abzufangen. Lass das ganz raus da und schreib lieber mal einen Text, wie man Fehler sucht. (Das wird sowieso in den meisten (allen?) Tutorials unterschlagen und täte mal Not.)

echo "$verabschiedung $name";

[Julian von Mendel]

Hi,

danke dir!

Schöne Grüße
Julian

[Julian von Mendel]

Hi,

Wenn du Quellcode durch Einrückungen formatierst, und dann auch noch Leerzeichen einfügst, dass bestimmte Dinge untereinander stehen (in meinen Augen unnötiger Aufwand / Mikrooptimierung) solltest du bei der Ausgabe auf der Weseite eine diktengleiche Schriftart verwenden, sonst geht der Effekt verloren.

korrigiert.

Konstante Stringwerte, vor allem wenn sie als Parameter übergeben werden sollen, könnten als (Klassen-)Konstanten hinzugefügt werden. Codevervollständiger können Tipparbeit bei Konstanten abnehmen, aber nicht bei Strings.

Hast du Beispiele, wo du das einsetzen würdest?

XML verlangt geringfügig andere Maskierungen als htmlspecialchars in der Grundeinstellung berücksichtigt (')

Korrigiert.

Callbacks kann man vor dem Aufruf und auch schon beim Entgegennehmen mit is_callable() auf Ausführbarkeit testen.

Korrigiert.

Schöne Grüße
Julian

[dedlfix]

echo $begrüßung;

Konstante Stringwerte, vor allem wenn sie als Parameter übergeben werden sollen, könnten als (Klassen-)Konstanten hinzugefügt werden. Codevervollständiger können Tipparbeit bei Konstanten abnehmen, aber nicht bei Strings.

Hast du Beispiele, wo du das einsetzen würdest?

Ja, gleich zu Anfang fiel mir das auf, bei den Parametern zur Methode output.

class xml {
  const RETURN_XHTML = 'xhtml';
  const DOCTYPE_XHTML_STRICT = 'xhtml1-strict';

function output($xml, $returntype = self::RETURN_XHTML, $doctype = self::DOCTYPE_XHTML_STRICT) {...}
}

Dabei geht es mir weniger darum, diese Konstanten in der Methodendeklaration zu verwenden, als eher dem IDE-mit-Codevervollständigung-Anwender beim Aufruf der Methode den Komfort der Konstanten zu bieten.

Überall da, wo du sonst noch das Verhalten mittels festgelegter Stringwerte steuerst, bietet sich die Deklaration von Konstanten an. Ob der Anwender lieber einen Stringwert als eine Konstante verwendet unterliegt dann immer noch seiner freien Entscheidung.

echo "$verabschiedung $name";

[Detlef G.]

Hallo Julian

... Ich nehme auch Verbesserungsvorschläge für die Website selbst an.)

Zu den Seiten mit den Quelltextanzeigen:
Lass die Breitenangabe für den Quelltextcontainer weg, damit das gesamte Browserfenster bei langen Zeilen horizontal gescrollt werden kann. Es ist lästig, immer erst ans Seitenende scrollen zu müssen.

Auf Wiederlesen
Detlef

[Julian von Mendel]

Hi Detlef,

... Ich nehme auch Verbesserungsvorschläge für die Website selbst an.)

Zu den Seiten mit den Quelltextanzeigen:
Lass die Breitenangabe für den Quelltextcontainer weg, damit das gesamte Browserfenster bei langen Zeilen horizontal gescrollt werden kann. Es ist lästig, immer erst ans Seitenende scrollen zu müssen.

ich habe keine Breite vorgegeben?

Schöne Grüße
Julian

[dedlfix]

echo $begrüßung;

Lass die Breitenangabe für den Quelltextcontainer weg, damit das gesamte Browserfenster bei langen Zeilen horizontal gescrollt werden kann. Es ist lästig, immer erst ans Seitenende scrollen zu müssen.
ich habe keine Breite vorgegeben?

Das nicht, aber Abstände zum Rand und ein overflow.

Außerdem gibts nun auf dem angegebenen Link zur Klassenbeschreibung einen 404er. Die neue URL ist http://derjulian.net/php/xml.

echo "$verabschiedung $name";

[Julian von Mendel]

Hi,

Das nicht, aber Abstände zum Rand und ein overflow.

Lasse ich das overflow weg und es passt?

Außerdem gibts nun auf dem angegebenen Link zur Klassenbeschreibung einen 404er. Die neue URL ist http://derjulian.net/php/xml.

Sorry. Ich habe die Testversion als endgültige online gestellt und im Rahmen dessen die alte Subdomain gelöscht.

Schöne Grüße
Julian

[Detlef G.]

Hallo Julian

ich habe keine Breite vorgegeben?

Sorry.

Mir fallen folgende grundsätzliche Möglichkeiten ein:

• overflow:visible belassen
    (dann reichen lange Zeilen allerdings über den Rahmen hinaus)
• die Höhe soweit begrenzen, dass die Scrollbalken im Fenster bleiben
    (auch nicht schön, und woher die Höhe nehmen)
• eine Breite entsprechend der längsten Zeile angeben
    (woher die allerdings nehmen, die ist bei jeder Seite anders)
• float verwenden, damit sich die Breite der Box an die Breite des Inhalts anpassen kann

Auf Wiederlesen
Detlef