bisher mit nicht bekannte Syntax bei Def. v. Funktionsparamtern

[frankx]

Hellihello

im Zend-Framwork lese ich in einer Klasse (Front.php):

public function dispatch(Zend_Controller_Request_Abstract $request = null, Zend_Controller_Response_Abstract $response = null)

nur die jeweiligen Vars mit einer Zuweisung kenne ich, das ist dann der Defaultwert, falls kein Param übergeben wird. Was aber ist "Zend_Controller_Request_Abstract"..., wieos steht das da, was bedeutet es?

Dank und Gruß,

frankx

[Peter Pan]

Hi!

im Zend-Framwork lese ich in einer Klasse (Front.php):

Du beschäftigst Dich mit dem Zend-FW - gute Idee!
Nimm Dir Zeit!
Wenn Du es richtig benutzen kannst, willst Du es nicht mehr missen wollen.

  

>     public function dispatch(Zend_Controller_Request_Abstract $request = null, Zend_Controller_Response_Abstract $response = null)  

Dies ist das mit PHP 5 eingeführte Type hinting - $request muss ein Exemplar von Zend_Controller_Request_Abstract, bzw. ein Objekt einer davon abgeleiteten Klasse sein.

Im speziellen Fall letzteres, da man abstrakte Klassen nicht instanziieren kann.

Da die beiden Parameter in der Signatur vorbelegt sind, kannst Du die Methode aber auch ohne Parameter aufrufen - übergibst Du aber z.B: einen String, oder ein Array, heult PHP rum.

Mit diesem Feature soll etwas mehr Typ-Sicherheit in PHP geschaffen werden - es funktioniert nur für Objekte und Arrays - nicht für skalare Typen.

frankx
off:PP

[frankx]

Hellihello

Hi!

im Zend-Framwork lese ich in einer Klasse (Front.php):

Du beschäftigst Dich mit dem Zend-FW - gute Idee!
Nimm Dir Zeit!
Wenn Du es richtig benutzen kannst, willst Du es nicht mehr missen wollen.

http://www.codedifferent.com/2008/04/02/ruby-on-rails-or-zend-framework-–-deciding-now/#comments hatte mich unter anderem auf dem Weg dahin bestärkt. Es ist ja doch recht voluminös aber sicherlich kann man nicht von sich behaupten, PHP zu "beherrschen", wenn einem die Logik dieses FW inklusive Coding-Standards, best practices, Ordernstruktur, MVC-Umsetzung und Dokumentation (PHPDocumentor) nicht bekannt bzw. plausibel sind.

Für Mini-Sites mit ein paar Seiten vermutlich etwas "overdone" (;-).

Mit diesem Feature soll etwas mehr Typ-Sicherheit in PHP geschaffen werden - es funktioniert nur für Objekte und Arrays - nicht für skalare Typen.

Was ist der Vorteil, hier eine Typenvorgabe in der Deklaration zu machen, statt die übergebenden Vars innerhalb der Funktion auf Typ zu prüfen (if instance_off("classename",§request) ... zB., oder is_array().

Dank und Gruß,

frankx

[Peter Pan]

Hi!

im Zend-Framwork lese ich in einer Klasse (Front.php):

Du beschäftigst Dich mit dem Zend-FW - gute Idee!
Nimm Dir Zeit!
Wenn Du es richtig benutzen kannst, willst Du es nicht mehr missen wollen.

Es ist ja doch recht voluminös

Ja und seit mit Release 1.0 der Blödsinn aufgehört hat, immer wieder Schnittstellen zu ändern, ist es außerdem gut dokumentiert - auch mehrsprachig.

aber sicherlich kann man nicht von sich behaupten, PHP zu "beherrschen", wenn einem die Logik dieses FW inklusive Coding-Standards, best practices, Ordernstruktur, MVC-Umsetzung und Dokumentation (PHPDocumentor) nicht bekannt bzw. plausibel sind.

Meinst du damit jetzt Dich, oder mich? ;)

Ich meinte mit 'richtig benutzen kannst' das Framework - was wiederum voraussetzt, dass man PHP zumindest 'gut' kennen sollte.

PHP 'zu beherrschen' ist etwas anderes - das tun ja noch nichtmal die Core-Developer, wie man leicht merkt, wenn man mal die diversen 'Ergüsse' auf der Mailing-List gelegentlich betrachtet.

Für Mini-Sites mit ein paar Seiten vermutlich etwas "overdone" (;-).

Klar!
Ich gehe zu Fuß zum Bäcker gegenüber und absolviere dafür keine Pilotenaubildung, um dann festzustellen, dass der Bäcker mir keine Landeerlaubnis auf seinem Dach erteilen wird;)

Was ist der Vorteil, hier eine Typenvorgabe in der Deklaration zu machen, statt die übergebenden Vars innerhalb der Funktion auf Typ zu prüfen (if instance_off("classename",§request) ... zB., oder is_array().

Es gibt keinen - das ist der Nachbau von Features anderer Sprachen!

Natürlich könnte man jetzt sagen, dass PHP vor der Verarbeitung der Daten innerhalb einer Funktion/Methode jammert, aber: wer übergebene Daten innerhalb einer Methode nicht prüft, wird auch kein Type Hinting benutzten.

off:PP

[frankx]

Hellihello

Ja und seit mit Release 1.0 der Blödsinn aufgehört hat, immer wieder Schnittstellen zu ändern, ist es außerdem gut dokumentiert - auch mehrsprachig.

Jau, da bin ich auch schon, auch beim Quickstart.

Nicht finden finde ich aber, wieso der "IndexController.php" überhaupt aufgerufen wird.

Dank und Gruß,

frankx

[Peter Pan]

Hi!

Nicht finden finde ich aber,

Wow das liest sich lustig;)

wieso der "IndexController.php" überhaupt aufgerufen wird.

Das macht die Bootstrap-Datei namens index.php;)

An welcher Stelle bist Du bei Deiner Beschäftigung mit dem MVC-Ansatz vom Zend-FW?

Hast Du eine lauffähige Version installiert, oder liest du gerade nur?

off:PP

[frankx]

Hellihello

wieso der "IndexController.php" überhaupt aufgerufen wird.

Das macht die Bootstrap-Datei namens index.php;)

Also meine index.php im /docroot

  
<?php  
// Step 1: Set a flag indicating setup is necessary  
$bootstrap = true;  
  
// Step 2: Perform application-specific setup  
// This allows you to setup the MVC environment to utilize. Later you can re-use this file for testing your applications  
require '../application/bootstrap.php';  
  
// Step 3:  Dispatch the request using the front controller.  
// $frontController is created in your boostrap file. Now we'll dispatch it, which dispatches your application.  
$frontController->dispatch();  

An welcher Stelle bist Du bei Deiner Beschäftigung mit dem MVC-Ansatz vom Zend-FW?

Ich habe den Quickstart http://framework.zend.com/wiki/display/ZFDEV/Official+ZF+QuickStart versucht zu bauen, mit Erfolg - es "funzt" -, und versuche jetzt dem Code zu folgen.

In der index.php wird die ../application/bootstrap.ini aufgerufen. Darin wird der auto_load konfiguriert und ein $frontController instanziiert.

  
$frontController->setControllerDirectory('../application/controllers');  

So wird wohl das Verzeichnis gesetzt, in dem der IndexController.php und der ErrorController.php liegt.

In meinem jetzigen IndexController wir gemäß Beipsiel ein Formular eingerichtet, das dann in der ../application/views/script/index.phtml mit <?= $this->form;?> zur Anzeige gebracht wird.

Aber so ganz, s. meine Frage, habe ich den Ablauf noch nicht lesend nachvollziehen können. U.a. auch wegen unbekannter Syntax (s. O.P.).

Den Refernce-Guide durchzulesen bringt ja wohl wenig, eine andere Anleitung habe ich bisher irgendwie scheinbar übersehen. Ich dachte auch schon insgeheim: "vielleicht hilfts ja, das Grundkonstrukt (deshalb wohl auch Dein Hinweis aufs MVC") erstmal zu kapieren".

Hast Du eine lauffähige Version installiert, oder liest du gerade nur?

Jau, lokal und auf einem Server im Netz - Quickstart und alle Klassen in der geforderten Struktur.

Dank und Gruß,

frankx

[frankx]

Hellihello

Den Refernce-Guide durchzulesen bringt ja wohl wenig, eine andere Anleitung habe ich bisher irgendwie scheinbar übersehen. Ich dachte auch schon insgeheim: "vielleicht hilfts ja, das Grundkonstrukt (deshalb wohl auch Dein Hinweis aufs MVC") erstmal zu kapieren".

Naja - Refernz-Hanbuch bringt ja doch Antworten, wenn man dann bis zum Action-Controller scrollt (gewusst wo suchen (;-)):

"7.1.2.5. Den Action-Controller für die Startseite erstellen

Bevor wir von Action-Controllern reden, sollte erst verstanden werden, wie Anfragen im Zend Framework behandelt werden. Standardmäßig zeigt das erste Segment eines URL auf einen Controller und das zweite Segment auf eine Aktion, die dieser Controller ausführen soll. Als Beispiel sei der URL http://framework.zend.com/roadmap/components gegeben. Der Pfad ist /roadmap/components, was die Anfrage zum Controller roadmap und dort in die Aktion components leitet. Wenn keine Aktion angegeben wird, wird index als Standard-Aktion angenommen, und wenn kein Controller angegeben wird, wird auch index als Standard-Controller angenommen. (Das folgt der Apache-Konvention, die einen DirectoryIndex automatisch findet).

Der Dispatcher von Zend_Controller nimmt dann den Wert, der als Controller angegeben ist, und schließt daraus auf eine passende Klasse. In der normalen Einstellung des Dispatchers wird der erste Buchstabe jedes Wortes im Controller-Namen groß geschrieben (Title-case), und dann das Wort Controller angehängt. Das bedeutet für unser Beispiel, dass die Anfrage nach dem Controller roadmap an die Klasse RoadmapController weitergeleitet wird.

Auf ähnliche Art wird die Methode für die Aktion bestimmt, die der Controller ausführen soll. In der Grundeinstellung wird die angefragte Aktion komplett kleingeschrieben und das Wort Action wird angehängt. In unserem Beispiel wird also die Aktion components zu componentsAction, insgesamt wird also die Methode RoadmapController::componentsAction() aufgerufen."

Habischgradprobiert und "funzt"...;

Dank und Gruß,

frankx

[Peter Pan]

Hi!

Habischgradprobiert und "funzt"...;

Kommwiederherwennnichtfunzt :L

off:PP

[Sympatisant]

Salvete,

folgende Methode angenommen:

public function dosth($val1 = 12, $val2 = 15) {}

Woher weiss der Interpreter welchen Parameter ich meine, wenn ich nur einen angebe?
dosth(11)

MfG,
Sympatisant

[frankx]

Hellihello

das geht _nur_ von rechts nach links - s.a. Dokumentation.

Dank und Gruß,

frankx

[Peter Pan]

Hi!

public function dosth($val1 = 12, $val2 = 15) {}

Woher weiss der Interpreter welchen Parameter ich meine, wenn ich nur einen angebe?
dosth(11)

In diesem Fall ist es der erste -  von links nach rechts werden die übergebenen Parameter ausgewertet, Du kannst keinen 'überspringen'.

off:PP

[frankx]

Hellihello,

in meinem Beispielcode erzeugt der IndexController

  
  
 public function indexAction()  
    {  
        $form = $this->getCommentForm();  
  
        if ($this->getRequest()->isPost()) {  
            if ($form->isValid($_POST)) {  
                $comment = $form->getValue('comment');  
                $this->view->comment = $comment;  
            }  
        }  
  
        $this->view->form = $form;  
    }  
    /**  
     * This function returns a simple form for adding a comment  
     */  
    public function getCommentForm()  
    {  
        $form = new Zend_Form(array(  
            'method'   => 'post',  
            'elements' => array(  
                'comment' => array('textarea', array(  
                    'required' => true,  
                    'label' => 'Please Comment:'  
                )),  
                'submit' => array('submit', array(  
                    'label' => 'Add Comment'  
                ))  
            ),  
        ));  
  
        return $form;  
    }  
  

also eine Instanz eine Zend_Form Objektes. In der view index.phtml wird diese Form schlicht mit

  
   <?= $this->form; ?>  

ausgegeben. PHPs short_open_tags sind mir geläufig. Warum aber gibt das echo einer Objektinstanz einen Formularquelltext wieder? Gibt es in PHP ein toString-Methode, wie sie mir wohl schon bei Javascript untergekommen ist? Aber es gibt ja kein Prototyping...; irgendwie riechts nach Holzweg. Ein var_dump des $this->form bringt Unmengen an Code.

Dank und Gruß,

frankx

[frankx]

Hellihello

<?= $this->form; ?>

  
Immerhin findet sich in der Doku dazu:  
  
"Standardmäßig versuchen Zend\_Form und Zend\_Form\_Element ein im ViewRenderer initialisiertes View Objekt zu verwenden, was bedeutet das die View nicht manuell gesetzt werden muß wenn das Zend Framework MVC verwendet wird. Die Darstellung einer Form in einem View Skript ist so einfach wie:  
  
<?= $this->form ?>  
  
Unter der Hand verwendet Zend\_Form "Dekorators" um die Darstellung durchzuführen. Diese Dekoratore können Inhalte ersetzen, Inhalte anfügen oder Inhalte voranstellen, und haben eine volle Introspektive des Elements das Ihnen übergeben wurde."  
  
Wobei ein Decorator ja nichts mit der Ausgabe duch "echo" zu tun hat, oder?  
  
Dank und Gruß,  
  
[frankx](http://community.de.selfhtml.org/visitenkarten/view.php?key=82)

-- 
[tryin to](http://sauer-ernst.de) [multitain](http://multitain.de)  - Globus = Planet != Welt 

[dedlfix]

echo $begrüßung;

Wobei ein Decorator ja nichts mit der Ausgabe duch "echo" zu tun hat, oder?

Ja, hat es nicht. Ich empfehle, dringend, dass du dir das PHP-Handbuchkapitel Classes and Objects (PHP 5) durcharbeitest. Das Zend Framwork macht heftigsten Gebrauch von PHP5s OOP-Features. Es gibt einige Magic Methods, unter anderem __toString(), mit der man einem Objekt mehr als eine Fehlermeldung entlocken kann, wenn man es in einen String-Kontext bringt.

Anschließend wäre eine Einführung in die SPL angebracht. Auch damit kann man einige Magie zu Klassen hinzufügen, wie beispielsweise Array-Zugriff und Iteration über Objekte. Das wird ebenfalls im Zend Framework verwendet. Die SPL ist aber recht umfangreich, und man benötigt meist nur den kleinen Teil, der auch in den Tutorials abgehandelt wird. In der Introduction zur SPL ist ein Link auf eine ausführlichere Beschreibung zu finden. Dort gibt es auch Links zu Einsteigerartikeln.

echo "$verabschiedung $name";

[frankx]

Hellihello dedlfix,

Ja, hat es nicht. Ich empfehle, dringend, dass du dir das PHP-Handbuchkapitel Classes and Objects (PHP 5) durcharbeitest.

Nun gut, mit "durcharbeiten" wird es wohl noch ein bisschen dauern. Immerhin aber entdecke ich dort die schon mal die beiden Punkte, die mir vor diesem Post nicht klar waren, nämlich das Type-Hinting und auch die von Dir auch unten erwähnte __toString Methode.

Das Zend Framwork macht heftigsten Gebrauch von PHP5s OOP-Features. Es gibt einige Magic Methods, unter anderem __toString(), mit der man einem Objekt mehr als eine Fehlermeldung entlocken kann, wenn man es in einen String-Kontext bringt.

Feine Sache das, gibts ja bei Javascript so auch object.toString oder so.

Anschließend wäre eine Einführung in die SPL angebracht. Auch damit kann man einige Magie zu Klassen hinzufügen, wie beispielsweise Array-Zugriff und Iteration über Objekte.

Iteration mittels foreach über die public-vars einer Klasseninstanz geht doch aber auch ohne, oder versteh ich was falsch? Immerhin aber wird klarer, was die spl_register_autoload macht, mit der das ZF ja seine Konventionsbenamung "Zend_Klassenkategorie_Klassenname" in 'Zend/Klassenkategorie/Klassenname.php' zum Laden anweist.

Dort gibt es auch Links zu Einsteigerartikeln.

Merci, auf jeden Fall weiß ich jetzt, wo weitersuchen!

Einsteigerartikel, meintest du damit http://www.php.net/~helly/php/ext/spl/? Sonst fand ich erstmal nischt.

Kleine Frage vielleicht anbei: wie verstehe ich das hier -

interface RecursiveIterator extends Iterator
interface OuterIterator extends Iterator
class RecursiveIteratorIterator implements OuterIterator

RecursiveItereatr extends Iterator. Das ist klar. Ein "interface" wiederum kann nur "implementiert" werden. Wobei aber Implementierung eigentlich bedeutet, dass die implementierte Interfaceklasse lediglich (!) vorschreibt, welche Methoden die implementierende Klasse enthalten muss. Intuitive Frage dazu: was soll das dann? Fehlerkontrolle?

Dank und Gruß,

frankx

[dedlfix]

echo $begrüßung;

Iteration mittels foreach über die public-vars einer Klasseninstanz geht doch aber auch ohne, oder versteh ich was falsch?

Es ist nicht immer wünschenswert, über alle Eigenschaften zu iterieren. Es gibt je nicht nur Daten sondern auch Metadaten, die so eine Klasse speichern kann.

Einsteigerartikel, meintest du damit http://www.php.net/~helly/php/ext/spl/? Sonst fand ich erstmal nischt.

Im rechten Frame etwas runterrollen, Punkt 9 meinte ich.

RecursiveItereatr extends Iterator. Das ist klar. Ein "interface" wiederum kann nur "implementiert" werden. Wobei aber Implementierung eigentlich bedeutet, dass die implementierte Interfaceklasse lediglich (!) vorschreibt, welche Methoden die implementierende Klasse enthalten muss. Intuitive Frage dazu: was soll das dann? Fehlerkontrolle?

Wenn eine Klasse ein Interface implementiert, dann ist sichergestellt, dass die im Interface definierten Dinge in der implementierenden Klasse vorhanden sind. Ein Anwender kann ein ihm übergebenens Objekt auf instanceof Interfacename testen und sich dann sicher sein, dass die im Interface vereinbarten Dinge vorhanden und zugreifbar sind.

echo "$verabschiedung $name";

[frankx]

Hellihello

Iteration mittels foreach über die public-vars einer Klasseninstanz geht doch aber auch ohne, oder versteh ich was falsch?

Es ist nicht immer wünschenswert, über alle Eigenschaften zu iterieren. Es gibt je nicht nur Daten sondern auch Metadaten, die so eine Klasse speichern kann.

Gut, sowas ist vermutlich dann am Plausibelsten in einer Beispielanwendung (vermutlich irgendwo auch dann im ZF). Ich hatte bisher bei meinem Gehirnjogging zu allgemeinen Datensatzstrukture dann überlegt

class Datensatz
{
  $meta_data = array();
  $data = array();
}
so dass dann über $user_instance->data["some_item1"] bzw. entsprechende Rückgabemethode zuegriffen bzw. über das data-Array oder in PHP-Bedeutung Hash (=assoziatives Array) iteriert werden könnte.

Unbsehen glaub ich oder nehm zur Kenntnis, dass vermutlich auch in umfangreicheren Zusammenhängen da abstraktere Möglichekeiten sinnvoll sind.

Einsteigerartikel, meintest du damit http://www.php.net/~helly/php/ext/spl/? Sonst fand ich erstmal nischt.

Im rechten Frame etwas runterrollen, Punkt 9 meinte ich.

Fein, jetzt habichs.

RecursiveItereatr extends Iterator. Das ist klar. Ein "interface" wiederum kann nur "implementiert" werden. Wobei aber Implementierung eigentlich bedeutet, dass die implementierte Interfaceklasse lediglich (!) vorschreibt, welche Methoden die implementierende Klasse enthalten muss. Intuitive Frage dazu: was soll das dann? Fehlerkontrolle?

Wenn eine Klasse ein Interface implementiert, dann ist sichergestellt, dass die im Interface definierten Dinge in der implementierenden Klasse vorhanden sind. Ein Anwender kann ein ihm übergebenens Objekt auf instanceof Interfacename testen und sich dann sicher sein, dass die im Interface vereinbarten Dinge vorhanden und zugreifbar sind.

Also eben Code-Sichheit. Vermutlich steht meinem Verständnis bzw. stand immer im Wege, dass ich dachte oder hoffte, über die Implementierung eines Interfaces gleich auch Methoden mitzuimplementieren (was ja sowas wie eine multiple Vererbung wäre, bzw. dass eine Klasse von mehreren Klassen erben könnte).

Dank und Gruß,

frankx

[dedlfix]

echo $begrüßung;

Unbsehen glaub ich oder nehm zur Kenntnis, dass vermutlich auch in umfangreicheren Zusammenhängen da abstraktere Möglichekeiten sinnvoll sind.

Man kann natürlich immer eine Eigenschaft erstellen, die man gezielt ansprechen kann. Manchmal ist es aber schöner, wenn man nicht $objekt->eigenschaft / $objekt->methode() notieren muss sondern direkt $objekt angeben kann. Besonders an Stellen, an denen "normale" Variablen und Objekte gemischt übergeben werden können, oder man einfach die Implementierungsdetails "verstecken" will (nicht um sie zu schützen, sondern weil man sie nicht ständig benötigt und darauf hingewiesen werden will).

Wenn eine Klasse ein Interface implementiert, dann ist sichergestellt, dass die im Interface definierten Dinge in der implementierenden Klasse vorhanden sind. Ein Anwender kann ein ihm übergebenens Objekt auf instanceof Interfacename testen und sich dann sicher sein, dass die im Interface vereinbarten Dinge vorhanden und zugreifbar sind.
Also eben Code-Sichheit.

Jein. Es ist nicht die Sicherheit, die man landläufig meint, sondern eher die Sicherstellung der Einhaltung eines Vertrages.

Vermutlich steht meinem Verständnis bzw. stand immer im Wege, dass ich dachte oder hoffte, über die Implementierung eines Interfaces gleich auch Methoden mitzuimplementieren (was ja sowas wie eine multiple Vererbung wäre, bzw. dass eine Klasse von mehreren Klassen erben könnte).

Nein, nicht mit PHP. Das Interface definiert, wie sein Name suggeriert, nur wie die Schnittstelle auszusehen hat. Was konkret die implementierende Klasse tun muss, um über die Schnittstelle zu kommunizieren, ist ihr Problem. Wenn du nach bereits vorgefertigten Dingen suchst, dann halte Ausschau nach abstrakten Klassen oder Klassen mit abstrakten Methoden. Diese haben im Allgemeinen bereits Funktionalität implementiert und müssen nur noch an den abstrakten Stellen ergänzt werden. Allerdings kann man Klassen ja nur einmal beerben.

echo "$verabschiedung $name";

[frankx]

Hellihello dedlfix,

Manchmal ist es aber schöner, wenn man nicht $objekt->eigenschaft / $objekt->methode() notieren muss sondern direkt $objekt angeben kann. Besonders an Stellen, an denen "normale" Variablen und Objekte gemischt übergeben werden können, oder man einfach die Implementierungsdetails "verstecken" will (nicht um sie zu schützen, sondern weil man sie nicht ständig benötigt und darauf hingewiesen werden will).

Aha!

Wenn eine Klasse ein Interface implementiert, dann ist sichergestellt, dass die im Interface definierten Dinge in der implementierenden Klasse vorhanden sind. Ein Anwender kann ein ihm übergebenens Objekt auf instanceof Interfacename testen und sich dann sicher sein, dass die im Interface vereinbarten Dinge vorhanden und zugreifbar sind.
Also eben Code-Sichheit.

Jein. Es ist nicht die Sicherheit, die man landläufig meint, sondern eher die Sicherstellung der Einhaltung eines Vertrages.

Jau, so meinte ich auch. Nicht die Sicherheit im Sinne von "knackbar" bzw. "hijackbar" oder "injectbar" oder so.

Nein, nicht mit PHP. Das Interface definiert, wie sein Name suggeriert, nur wie die Schnittstelle auszusehen hat.

Wenn das der Name "suggeriert", wo ist dann der "Schnitt", wo die "Stelle". Ich kapiere, was es ist, was es tut und was nicht, aber nicht, warum es so heißt. Vermutlich vermischt sich bei mir "Schnittstelle" und "Adapter".

Wenn du nach bereits vorgefertigten Dingen suchst, dann halte Ausschau nach abstrakten Klassen oder Klassen mit abstrakten Methoden. Diese haben im Allgemeinen bereits Funktionalität implementiert und müssen nur noch an den abstrakten Stellen ergänzt werden. Allerdings kann man Klassen ja nur einmal beerben.

Nein, das war jetzt eher nicht gemeint, sondern eher eben das von Dir erläuterte Grundmuster bzw. der Sinn von Implementierung und Schnittstelle allgemein.

Dank für die Erläuterungen

und Gruß,

frankx

[dedlfix]

echo $begrüßung;

Nein, nicht mit PHP. Das Interface definiert, wie sein Name suggeriert, nur wie die Schnittstelle auszusehen hat.
Wenn das der Name "suggeriert", wo ist dann der "Schnitt", wo die "Stelle". Ich kapiere, was es ist, was es tut und was nicht, aber nicht, warum es so heißt. Vermutlich vermischt sich bei mir "Schnittstelle" und "Adapter".

Beispiel API (Application Programming Interface): Ein API ist die Schnittstelle zwischen der Funktionalität, die eine Programm-Bibliothek bietet und dem anwendenden Programmierer. Es ist genau definiert, was der Programmierer aufrufen kann, welche Parameter er übergeben muss/kann und was er zurückbekommt.

Ein Interface in der OOP definiert, dass (unter anderem) bestimmte Methoden mit festgelegten Parametern und Rückgabewerten vorhanden sein müssen. Zurück zur SPL: Ein foreach kann sich bei einem Objekt einer Klasse, die das Iterator-Interface implementiert hat, darauf verlassen, auf dessen Methoden zu treffen, so dass es seine Arbeit erledigen kann. Was das Objekt sonst noch so kann, ist dem foreach egal.

echo "$verabschiedung $name";

[frankx]

Hellihello dedlfix,

Beispiel API (Application Programming Interface): Ein API ist die Schnittstelle zwischen der Funktionalität, die eine Programm-Bibliothek bietet und dem anwendenden Programmierer. Es ist genau definiert, was der Programmierer aufrufen kann, welche Parameter er übergeben muss/kann und was er zurückbekommt.

Ein Interface in der OOP definiert, dass (unter anderem) bestimmte Methoden mit festgelegten Parametern und Rückgabewerten vorhanden sein müssen. Zurück zur SPL: Ein foreach kann sich bei einem Objekt einer Klasse, die das Iterator-Interface implementiert hat, darauf verlassen, auf dessen Methoden zu treffen, so dass es seine Arbeit erledigen kann. Was das Objekt sonst noch so kann, ist dem foreach egal.

Der Groschen taumelt abwärts (;-). http://de.wikipedia.org/wiki/Schnittstelle_(objektorientierte_Programmierung) war zusätzlich ganz hilfreich.

Dank und Gruß,

frankx

[frankx]

Hellihello

Anschließend wäre eine Einführung in die SPL angebracht. Auch damit kann man einige Magie zu Klassen hinzufügen, wie beispielsweise Array-Zugriff und Iteration über Objekte.

  
<?php  
/*** create a new iterator object ***/  
$it = new DirectoryIterator('./');  
  
/*** loop directly over the object ***/  
while($it->valid())  
        {  
        /*** check if value is a directory ***/  
        if($it->isDir())  
                {  
                /*** echo the key and current value ***/  
                echo $it->key().' -- '.$it->current().'<br />';  
                }  
        /*** move to the next iteration ***/  
        $it->next();  
        }  
?>  

fein das, hatte mir bisher noch niemand gesagt, dass das alles auch so geht...; oder ich habs bisher nicht kapiert oder zwar gesehen aber irgendwie nich abgespeichert. so ein aha-erlebnis hatte ich vor einiger zeit mal mit der alternativen syntax (da dacht ich noch, es bräuchte eine extra templatesprach.

Dank und Gruß,

frankx

[dedlfix]

echo $begrüßung;

Anschließend wäre eine Einführung in die SPL angebracht. Auch damit kann man einige Magie zu Klassen hinzufügen, wie beispielsweise Array-Zugriff und Iteration über Objekte.

<?php
/*** create a new iterator object ***/
$it = new DirectoryIterator('./');

/*** loop directly over the object /
while($it->valid())
        {
        / check if value is a directory /
        if($it->isDir())
                {
                / echo the key and current value /
                echo $it->key().' -- '.$it->current().'<br />';
                }
        / move to the next iteration ***/
        $it->next();
        }
?>

>   
> fein das, hatte mir bisher noch niemand gesagt, dass das alles auch so geht...; oder ich habs bisher nicht kapiert oder zwar gesehen aber irgendwie nich abgespeichert. so ein aha-erlebnis hatte ich vor einiger zeit mal mit der alternativen syntax (da dacht ich noch, es bräuchte eine extra templatesprach.  
  
So sollst du das nicht anwenden. Das Iterator-Interface definiert die Methoden valid(), key(), current(), next(), und rewind(), damit eine Klasse die für ein foreach notwendigen Informationen bereitstellt. Diese Methoden sind nicht zum Aufruf durch den Anwender gedacht (im Gegensatz zu den isXxx()- und getXxx()-Methoden im Falle des DirectoryIterators). Anwenden sollst du ein foreach auf ein Objekt dieser Klasse:  
  
~~~php
foreach (new DirectoryIterator('test') as $entry) {  
  printf("%s ist ein%s\n",  
    $entry,  
    $entry->isDir() ? ' Verzeichnis' : 'e Datei');  
}

$entry ist übrigens ebenfalls ein DirectoryIterator-Objekt, über das man im Falle eines Verzeichnisses weiter iterieren kann.

echo "$verabschiedung $name";

[frankx]

Hellihello df,

echo $begrüßung;

Anschließend wäre eine Einführung in die SPL angebracht. Auch damit kann man einige Magie zu Klassen hinzufügen, wie beispielsweise Array-Zugriff und Iteration über Objekte.

<?php
/*** create a new iterator object ***/
$it = new DirectoryIterator('./');

/*** loop directly over the object /
while($it->valid())
        {
        / check if value is a directory /
        if($it->isDir())
                {
                / echo the key and current value /
                echo $it->key().' -- '.$it->current().'<br />';
                }
        / move to the next iteration ***/
        $it->next();
        }
?>

> >   
> > fein das, hatte mir bisher noch niemand gesagt, dass das alles auch so geht...; oder ich habs bisher nicht kapiert oder zwar gesehen aber irgendwie nich abgespeichert. so ein aha-erlebnis hatte ich vor einiger zeit mal mit der alternativen syntax (da dacht ich noch, es bräuchte eine extra templatesprach.  
>   
> So sollst du das nicht anwenden. Das Iterator-Interface definiert die Methoden valid(), key(), current(), next(), und rewind(), damit eine Klasse die für ein foreach notwendigen Informationen bereitstellt. Diese Methoden sind nicht zum Aufruf durch den Anwender gedacht (im Gegensatz zu den isXxx()- und getXxx()-Methoden im Falle des DirectoryIterators).  
  
found in <http://www.phpro.org/tutorials/Introduction-to-SPL.html#3>.  
  
gefolgt vom Kommentar: "So, now we have a list of directories within the path. But we could have done this in a more Object Oriented way that would allow us more flexibility. We begin by extending the DirectoryIterator class."  
~~~php
  
<?php  
/*** class definition to extend Directory Iterator class ***/  
class DirectoryReader extends DirectoryIterator {  
  
// constructor.. duh!  
function __construct($path){  
  /*** pass the $path off to the parent class constructor ***/  
  parent::__construct($path);  
}  
  
/*** return the current filename ***/  
function current(){  
  return parent::getFileName();  
}  
  
/*** members are only valid if they are a directory ***/  
function valid(){  
  if(parent::valid())  
    {  
    if (!parent::isDir())  
        {  
        parent::next();  
        return $this->valid();  
        }  
    return TRUE;  
    }  
  return FALSE;  
}  
  
} // end class  
  
try{  
/*** a new iterator object ***/  
$it = new DirectoryReader('./');  
/*** loop over the object if valid ***/  
while($it->valid())  
    {  
    /*** echo the current object member ***/  
    echo $it->current().'<br />';  
    /*** advance the internal pointer ***/  
    $it->next();  
    }  
}  
  
catch(Exception $e){  
    echo 'No files Found!<br />';  
}  
  
?>  

"The code above demonstrates how we can overload the Iterator methods to reduce the logic within the user code. This creates great opportunities to make portable classes for re-use, thus reducing user code and speeding up development time. Once again the use of Exceptions shows how easy it can be to catch errors and deal with them. We could, of course, use the isFile() method in place of isDir() to show only files. The possibilities are endless. "
 Anwenden sollst du ein foreach auf ein Objekt dieser Klasse:

foreach (new DirectoryIterator('test') as $entry) {

printf("%s ist ein%s\n",
    $entry,
    $entry->isDir() ? ' Verzeichnis' : 'e Datei');
}

>   
> $entry ist übrigens ebenfalls ein DirectoryIterator-Objekt, über das man im Falle eines Verzeichnisses weiter iterieren kann.  
>   
>   
> echo "$verabschiedung $name";  
  
  
Dank und Gruß,  
  
[frankx](http://community.de.selfhtml.org/visitenkarten/view.php?key=82)

-- 
[tryin to](http://sauer-ernst.de) [multitain](http://multitain.de)  - Globus = Planet != Welt 

[dedlfix]

echo $begrüßung;

found in http://www.phpro.org/tutorials/Introduction-to-SPL.html#3.

An dieser Stelle zeigt der Autor ja, wie der DirectorIterator normalerweise anzuwenden ist, nämlich mit foreach. Der Rest weiter unten stellt eher eine Art Demonstration dar, wie ein solche Klasse zu erweitern ist, und wie man sich das Zusammenspiel der Methoden vorstellen kann. Am Ende soll trotzdem ein foreach verwendet werden. Das ist auch deutlich einfacher anzuwenden als der direkte Aufruf der IteratorInterface-Methoden.

echo "$verabschiedung $name";

[frankx]

Hellihello

echo $begrüßung;

found in http://www.phpro.org/tutorials/Introduction-to-SPL.html#3.

An dieser Stelle zeigt der Autor ja, wie der DirectorIterator normalerweise anzuwenden ist, nämlich mit foreach. Der Rest weiter unten stellt eher eine Art Demonstration dar, wie ein solche Klasse zu erweitern ist, und wie man sich das Zusammenspiel der Methoden vorstellen kann. Am Ende soll trotzdem ein foreach verwendet werden. Das ist auch deutlich einfacher anzuwenden als der direkte Aufruf der IteratorInterface-Methoden.

Merci, solche Feinheiten fallen dem nicht so geübten Auge (meinem) "on the fly" ja erstmal nicht auf.

Dank und Gruß,

frankx

[frankx]

Hellihello,

"49.4.1.3.1. Konkrete Platzhalter Implementationen

Zend Framework kommt mit einer Anzahl an "konkreten" Platzhalter Implementationen. Diese sind für üblich verwendete Platzhalter: Doctype, Seitentitel, und verschiedene <head> Elemente. In allen Fällen gibt der Aufruf des Platzhalters ohne Argumente das Element selbst zurück."

zB.:

$this->headMeta()->appendName('keywords', 'framework php productivity');

Das lässt sich dann mit Verweis auf $this->... in "application\views\scripts\mytest\index.phtml" verwenden.

Nun sind Kopfdaten ja etwas, was zu teilen in jedem ..\scripts\controllClass\*.phtml gleich ist. Wo definiert man sowas dann am besten zentral? Bereits in der "/application/bootstrap.ini", in der im Quickstartskript bereits eine Instanz des FrontController erzeugt wird:

  
$frontController = Zend_Controller_Front::getInstance();  

???

Dank und Gruß,

frankx

[dedlfix]

echo $begrüßung;

Nun sind Kopfdaten ja etwas, was zu teilen in jedem ..\scripts\controllClass\*.phtml gleich ist. Wo definiert man sowas dann am besten zentral?

Wenn du ein Verhalten einer Klasse haben möchtest, das aber um weiteres, für alle Abnehmer immer gleichbleibendes Verhalten erweitern möchtest, bietet es sich an, eine abgeleitete Klasse zu erstellen, sie um das gewünschte Verhalten zu erweitern, und dann stets diese abgeleitete Klasse zu verwenden.

echo "$verabschiedung $name";

[frankx]

Hellihello

Wenn du ein Verhalten einer Klasse haben möchtest, das aber um weiteres, für alle Abnehmer immer gleichbleibendes Verhalten erweitern möchtest, bietet es sich an, eine abgeleitete Klasse zu erstellen, sie um das gewünschte Verhalten zu erweitern, und dann stets diese abgeleitete Klasse zu verwenden.

Gewisse Daten aber, so hatte ich gedacht, wären vielleicht auch controllerübergreifend gültig, so der Doctype, ein zentrales Layout (css).

Ansonsten wäre dann wohl in jedem *Controller eben die $controller->view entsprechend zu konfigurieren, so ich o.g. verstehe. Vermutlich der Zeitpunkt, etwas mehr in die Praxis einzusteigen. Bisher habe ich noch keine kleine Beispielanwendung gefunden, die über den "Quickstart" hinausgeht. Anwendungen zu studieren hilft ja oft, das zu kapieren.

Dank und Gruß,

frankx

[dedlfix]

echo $begrüßung;

Gewisse Daten aber, so hatte ich gedacht, wären vielleicht auch controllerübergreifend gültig, so der Doctype, ein zentrales Layout (css).

Das sind View-spezifische Dinge. Der Controller sollte sich um die Nutzdaten kümmern. Was die View machen muss, um die Daten für ein bestimmtes Medium aufzubereiten ist ihre Angelegenheit.

Ansonsten wäre dann wohl in jedem *Controller eben die $controller->view entsprechend zu konfigurieren, so ich o.g. verstehe.

Du solltest eine passende (bzw. angepasste) View verwenden. Du wirst ja wohl auch mehrere Controller haben und die View-Konfiguration nicht ständig anführen wollen. Deswegen verlagere diese Aufgabe in die View oder lass die View ein geeignetes Template wählen.

echo "$verabschiedung $name";

[frankx]

Hellihello dedlfix,

Das sind View-spezifische Dinge. Der Controller sollte sich um die Nutzdaten kümmern. Was die View machen muss, um die Daten für ein bestimmtes Medium aufzubereiten ist ihre Angelegenheit.

Ansonsten wäre dann wohl in jedem *Controller eben die $controller->view entsprechend zu konfigurieren, so ich o.g. verstehe.

Du solltest eine passende (bzw. angepasste) View verwenden. Du wirst ja wohl auch mehrere Controller haben und die View-Konfiguration nicht ständig anführen wollen. Deswegen verlagere diese Aufgabe in die View oder lass die View ein geeignetes Template wählen.

Das kapier ich alles, aber wo finde ich "die View". Einmal taucht sie in $frontController->view auf.

Dann in den einzelnen Scripts "/controller/views/controllername/methodname.phtml". Aber in letzterem will ich ja nich ein jedem einzelnen immer wieder auf die eine selbe css-Datei hinweisen, oder?

Naja, manchmal hakts halt beim vielen "nur lesen". Und eine kleine Example- Anwendung (außer dem Quickstart) zum abgucken konnte ich noch nicht finden. Komisch eigentlihc, dass hier im Forum so wenig damit zu tun haben scheinbar.

Dank und Gruß,

frankx

[dedlfix]

echo $begrüßung;

Das kapier ich alles, aber wo finde ich "die View". Einmal taucht sie in $frontController->view auf.
Dann in den einzelnen Scripts "/controller/views/controllername/methodname.phtml". Aber in letzterem will ich ja nich ein jedem einzelnen immer wieder auf die eine selbe css-Datei hinweisen, oder?

Nun ja ... seit ich mich das letzte Mal mit dem ZF beschäftigt habe sind eine Menge neue Dinge eingebaut worden, stellte ich grad fest. Früher übergab man dem ActionController noch selbst die View. Heute gibt es einen Default-Mechanismus, der (vermutlich) ein Zend_View-Objekt instantiiert, in einer vorgegebenen Verzeichnisstruktur nach einem Template sucht, das dem View-Objekt zuweist und zu gegebener Zeit rendert. Diesen Mechanismus kannst du überschreiben. initView() zu überschreiben scheint mir der passende Einstieg. Am besten schaust du in den Quelltext, was diese Methode konkret macht, und was du in einer von Zend_Controller_Action abgeleiteten Klasse machen musst, damit ein Objekt einer abgeleiteten, erweiterten Zend_View-Klasse geladen wird. Deine eigenen Kontrollerklassen lässt du dann von dieser Klasse statt von Z_C_A erben.

Komisch eigentlihc, dass hier im Forum so wenig damit zu tun haben scheinbar.

Es ist für das typische Publikum hier vermutlich zu komplex - mit Kanonen auf Gästebücher geschossen. Man muss dazu ja OOP einigermaßen verstanden haben und wird dann auch noch mit MVC und anderen Konzepten konfrontiert. Es ist auch nicht sehr leicht, die Arbeitsweise zu verstehen. Während man im Wald&Wiesen-Script ständig die Kontrolle hat, bis auf die Stellen, an denen ein Funktionsaufruf in die Tiefen PHPs abtaucht, arbeitet das ZF hauptsächlich unter der Oberfläche und taucht gelegentlich auf, um User-Code zu verarbeiten.

echo "$verabschiedung $name";

[frankx]

Hellihello

Das kapier ich alles, aber wo finde ich "die View". Einmal taucht sie in $frontController->view auf.
Dann in den einzelnen Scripts "/controller/views/controllername/methodname.phtml". Aber in letzterem will ich ja nich ein jedem einzelnen immer wieder auf die eine selbe css-Datei hinweisen, oder?

Nun ja ... seit ich mich das letzte Mal mit dem ZF beschäftigt habe sind eine Menge neue Dinge eingebaut worden, stellte ich grad fest. Früher übergab man dem ActionController noch selbst die View. Heute gibt es einen Default-Mechanismus, der (vermutlich) ein Zend_View-Objekt instantiiert, in einer vorgegebenen Verzeichnisstruktur nach einem Template sucht, das dem View-Objekt zuweist und zu gegebener Zeit rendert. Diesen Mechanismus kannst du überschreiben. initView() zu überschreiben scheint mir der passende Einstieg. Am besten schaust du in den Quelltext, was diese Methode konkret macht, und was du in einer von Zend_Controller_Action abgeleiteten Klasse machen musst, damit ein Objekt einer abgeleiteten, erweiterten Zend_View-Klasse geladen wird. Deine eigenen Kontrollerklassen lässt du dann von dieser Klasse statt von Z_C_A erben.

Gut zu wissen. Das dauert dann wohl ein Momentchen (;-).

Komisch eigentlihc, dass hier im Forum so wenig damit zu tun haben scheinbar.

Es ist für das typische Publikum hier vermutlich zu komplex - mit Kanonen auf Gästebücher geschossen. Man muss dazu ja OOP einigermaßen verstanden haben und wird dann auch noch mit MVC und anderen Konzepten konfrontiert. Es ist auch nicht sehr leicht, die Arbeitsweise zu verstehen. Während man im Wald&Wiesen-Script ständig die Kontrolle hat, bis auf die Stellen, an denen ein Funktionsaufruf in die Tiefen PHPs abtaucht, arbeitet das ZF hauptsächlich unter der Oberfläche und taucht gelegentlich auf, um User-Code zu verarbeiten.

Was sind denn die "Tiefen PHPs"?

Dass das ZF eben an der Oberfläche bedienbar ist, und auch selbst schreibt, dass der Hintergrund im Detail für einen "Nutzer" (also einen Entwickler auf ZF-Basis) nicht direkt relevant ist, heißt für mich aber im Umkehrschluss: PHP "richtig" verstehen, heißt auch alles rund um die spl und das OOP-Modell inklusive dem, wie ZF das nutzt, zu verstehen. Die abstrakten Hintergrundklassen sowie zB. die Nutzung bzw. Überschreibung der __autoload-Funktion (Loader.php), aber auch die magic_Methods (__toString) und die Einrichtung der von dir auch oben beschriebenen Defaultfunktionen (bezüglich der View, aber wohl auch des Dispatchers und vermutlich auch des Request- und Respons-Objektes). Der Quickstart lässt da so ein paar Konfigurationsmöglichkeiten noch ungenutzt, an Hand derer man sich ja sonst gut in die Tiefe hangeln könnte. Eigene Versuche gehen ja dann u.U. auch an sinnvollem "best practice" vorbei.

Dank und Gruß,

frankx

[frankx]

Hellihello

vom 13.8.2008 - also branneu?

"Introduction
I find myself constantly bombarded with questions from students and co-workers I've introduced to the Zend Framework regarding how the different components can come together to form a basic application. I've searched, I have found, I have emailed great tutorials, but still the most common questions are posed "What's should I include in index.php?", "Should I use Zend_Db_Table?", "And what about Zend_Form?""

http://www.developertutorials.com/tutorials/php/zend-framwork-tutorial-8-08-13/page1.html

found in http://www.dynamic-webpages.de/tutorial/61/spl unter "Tutorials".

Leider nicht als Download, die Beispielanwendung.

[frankx](

Dank und Gruß,

[link:http://community.de.selfhtml.org/visitenkarten/view.php?key=82)