Superklasse Variablen in Subklasse kennzeichnen
MB
- php
- programmiertechnik
Moin Community,
wie kann ich mir selbst versichern das Protected Properties der Superklassen in Subklassen per inheritance zu verführung stehen? Gibts da ne Art "Comment Convention" der PHPDoc oder muss ich das mir selbst bei bringen ungefähr so...
class Fubar {
/** @var string foo */
protected foo;
/** @var string bar */
protected bar;
}
class Quz extends Fubar {
/** @var string foo */
/** @var string bar */
}
oder selbst was ausdenkn sowas wie /** @var string foo (@inherit) */
vlg MB
NACHTRAG:
Gibt es eine PHP Convention die gepasten PHP-Variablen in HTML
regelt? Ich mein per include
gepaste Funktionsvariablen sind HTML
intern nicht sichbar. wie auch. In HTML
z.B. als Coder oder Webdesigner habe ich keinen blassen schimmer ob, welche, wieviele, Variablen nun geparst sind. Das kann ich, meines wissens nach, nur über den PHP-Code include
herausfinden. Die PHP-Datei die den View HTML
erzeugt.
Beispiel
view.php
class View {
/** @var array $data Home Content */
protected $data;
/** @var string $path view path html */
protected $path;
// ...
public function render( $data ) {
include $this->path;
}
}
index.html
<!DOCTYPE html>
<html>
<head></head>
<body>
<?= $data[ 'content' ]; ?>
</body>
</html>
bin mal gespannt.
vlg MB
Nur soviel:
include $this->path;
ist schlecht fürs Debugging. Gerade beim include
sollte man doch sofort rein optisch sehen können welche source da hinzukommt. Gibt es in PHP eine Möglichkeit dies nachträglich zu prüfen?
In Perl gibt es diese Möglichkeit und trotzdem haben sich solche Konstrukte immer wieder als schlecht erwiesen weil bei einer etwaigen Fehlersuche die Zeit davonläuft.
MfG
Tach!
Nur soviel:
include $this->path;
ist schlecht fürs Debugging. Gerade beim
include
sollte man doch sofort rein optisch sehen können welche source da hinzukommt.
Die View-Klasse, aus der die obige Zeile stammt, muss mit allen Templates umgehen können. Template-Namen fest zu verdrahten, damit man sehen kann, was da konkret inkludiert wird, würde bedeuten, separate View-Klassen für jedes Template zu erstellen, die sich nur in einem fest kodierten include-Parameter unterscheiden. Das ist noch schlechter fürs Gesamtprojekt als angeblich fürs Debugging. (Wenn man so will, wäre fürs Debugging alles schlecht, was als Variable hereingereicht wird, weil man nicht sehen kann, was zur Laufzeit an Wert übergeben werden wird.)
Gibt es in PHP eine Möglichkeit dies nachträglich zu prüfen?
Werte, die in Variablen stehen, können wie überall mit Kontrollausgaben sichtbar gemacht werden. Ob ein Wert als Pfadangabe für ein include verwendet wird, oder in irgendeiner anderen Art und Weise, spielt dabei keine Rolle.
dedlfix.
Hi pl,
vielen lieben dank für deine Aw. Wie machst du in PHP das den wenn nicht mit include
? zählt require
auch dazu?
vlg MB
Tach!
Wie machst du in PHP das den wenn nicht mit
include
? zähltrequire
auch dazu?
require ist quasi dasselbe wie include. Die beiden unterscheiden sich nur noch in der Art der Fehlermeldung, die beim Nichtladenkönnen erzeugt wird.
Ich fand die Antwort nicht weiter sinnvoll. Man programmiert nicht fürs Debugging, sondern weil man ein Ziel erreichen möchte. Wenn das Ziel ist, verschiedene Template-Dateinamen übergeben zu können, da muss man das mit einer Variable tun. Variablen sind gang und gäbe. Warum sollte das ausgerechnet beim Include ungünstig sein? Warum sollte man beim Include unbedingt sehen müssen, was prinzipbedingt auch bei anderen Verwendungsformen von Variablen nicht ohne Kontrollausgabe sichtbar ist? Include mit Variablen ist kein größeres Problem als die Verwendung von Variablen anderenorts.
dedlfix.
Tach!
Gibt es eine PHP Convention die gepasten PHP-Variablen in
HTML
regelt?
Nein, aber der Scope regelt das, was an welcher Stelle sichtbar ist.
Ich mein per
include
gepaste Funktionsvariablen sindHTML
intern nicht sichbar. wie auch.
include lädt den zu inkludierenden Code an die Stelle, an der das include-Statement steht. Du kannst im includierten Code auf alles zugreifen, was in diesem Scope zur Verfügung steht.
In
HTML
z.B. als Coder oder Webdesigner habe ich keinen blassen schimmer ob, welche, wieviele, Variablen nun geparst sind.
Das muss der Controller sicherstellen, dass diese im Scope des Renderprozesses sichtbar sind.
Das kann ich, meines wissens nach, nur über den PHP-Code
include
herausfinden. Die PHP-Datei die den ViewHTML
erzeugt.
Herauszufinden ist da nichts mehr. Zugreifen und darauf vertrauen, dass der Controller seine Arbeit richtig getan hat, und alles bereitgestellt hat, was die View braucht. Du testest ja deinen Code (TDD oder zu Fuß), dass er in allen Lebenslagen funktioniert und stellst gegebenenfalls dabei fest, ob was fehlt und der Controller oder das Model korrigiert werden muss.
Beispiel
view.php
class View { /** @var array $data Home Content */ protected $data; /** @var string $path view path html */ protected $path; // ... public function render( $data ) { include $this->path; } }
In dem inkludierten Code hast du nun Zugriff auf $data und $this.
dedlfix.
Du glaubst gar nicht, wie oft ich beim Entwickeln ein $this->dd();
notiere um zu gucken welche Eigenschaften in der Instanz mit welchen Werten initialisiert sind. Dump & die, natürlich kommt die Zeile wieder raus wenn alles geklärt ist. Du tust jedoch gut daran eine solche Methode in der Hinterhand zu haben zur gelegentlichen Kontrolle Deiner Datenstrukturen.
Tipp: Stelle für solche Fälle text/plain im Browser ein. MfG
Tach!
wie kann ich mir selbst versichern das Protected Properties der Superklassen in Subklassen per inheritance zu verführung stehen?
Das ist die grundlegende Eigenschaft von protected. Wenn es dir darum geht, dass da ein Wert enthalten sein soll, dann macht man das wie mit jeder anderen Eigenschaft auch, man weist ihn im Constructor zu.
Gibts da ne Art "Comment Convention" der PHPDoc
Mitglieder werden in der Klasse dokumentiert, in der sie enthalten sind. Die IDE findet auch zu diesen in geerbten Klassen enthaltenen Mitgliedern die Dokumentation. Du must weder Pseudo-Dokumentationen erstellen, noch die Mitglieder wiederholen oder anderweitig überschreiben (außer als abstract deklarierte).
dedlfix.