Zend 2

[heinetz]

Hallo Forum,

nachdem ich nun seit etwa 15 Jahren Websites mit PHP baue aber zum Einen immernoch nicht objektorientiert programmiere und zum Anderen immernoch dazu neige, alles immer wieder von Hand zu entwickeln, möchte ich mir an eine andere Herangehensweise angewöhnen. Mein Plan ist, mein nächstes Projekt mit Zend 2 zu realisieren. Meine Unsicherheit dabei ist, dass ich eigentlich garnicht weiss, was genau Zend 2 ist und wie ich am besten da einsteige. Natürlich habe ich schonen bisschen was dazu gelesen und mir das ein oder andere Video-Tutorial angesehen aber ich habe den Eindruck, es kann vieles sein und ich muss mich nun darum kümmern, in welchen Häppchen ich mir das Wissen am besten serviere und was ich in welcher Reihenfolge ausprobiere, um den Überblick zu behalten.

Wo fange ich am besten so an?

Danke für Tipps und

beste gruesse,
heinetz

[Sven Rautenberg]

Moin!

nachdem ich nun seit etwa 15 Jahren Websites mit PHP baue aber zum Einen immernoch nicht objektorientiert programmiere und zum Anderen immernoch dazu neige, alles immer wieder von Hand zu entwickeln, möchte ich mir an eine andere Herangehensweise angewöhnen. Mein Plan ist, mein nächstes Projekt mit Zend 2 zu realisieren. Meine Unsicherheit dabei ist, dass ich eigentlich garnicht weiss, was genau Zend 2 ist und wie ich am besten da einsteige. Natürlich habe ich schonen bisschen was dazu gelesen und mir das ein oder andere Video-Tutorial angesehen aber ich habe den Eindruck, es kann vieles sein und ich muss mich nun darum kümmern, in welchen Häppchen ich mir das Wissen am besten serviere und was ich in welcher Reihenfolge ausprobiere, um den Überblick zu behalten.

Wo fange ich am besten so an?

Ich denke, du solltest nicht mit Zend anfangen, sondern erstmal mit dem objektorientierten Programmieren an sich.

Im Prinzip ist die Frage ja: Weißt du genug über Objektorientierung, so dass du den Quellcode von irgendeinem objektorientierten Framework lesen und verstehen kannst? Ich weiß nicht, ob man das MUSS, aber für mich persönlich ist es sehr wertvoll, es zu tun: Erst wenn ich verstanden habe, wie die einzelnen Komponenten zusammenwirken, kann ich beurteilen, an welcher Stelle ich am besten ansetze, um den von mir gewünschten Effekt zu erhalten. Als Bonus habe ich dann relativ wenig eigenen Code zu schreiben, den ich hinterher dann auch zu pflegen habe. Man kann genausogut aber auch viel eigenen Code stattdessen schreiben und ihn pflegen - das Ergebnis wird gleich sein.

Trotzdem: Ohne Kenntnisse der Objektorientierung wirst du nicht so sehr weit kommen, weil beispielsweise Zend 2 dir nur für gewisse Dinge, die das Framework abdeckt, Unterstützung anbietet. Alles andere ist komplett deine eigene Aufgabe und muss, ohne dass du Unterstützung bekommst, komplett von dir objektorientiert gelöst werden. Ohne Kenntnisse ist das schwierig.

Ich würde außerdem behaupten, dass Zend 2 nicht unbedingt ein Framework für Framework-Anfänger ist, selbst wenn sie schon objektorientiert programmiert haben.

Aber du musst das ausprobieren. Die Installation ist nicht schwer (Composer), und danach kann man schon direkt irgendwas hinfummeln und erste Erfolge haben. Kommst du dann mit konkreten Fragen, kannst du auch konkrete Antworten bekommen.

- Sven Rautenberg

[dedlfix]

Tach!

Wo fange ich am besten so an?
Ich denke, du solltest nicht mit Zend anfangen, sondern erstmal mit dem objektorientierten Programmieren an sich.

Das finde ich auch. Es kommen da gleich zwei Dinge auf dich (heinetz) zu. Die ungewöhnte Objektorientierung ist das eine. Das andere ist die Umstellung der Herangehensweise an sich. Beim prozeduralen Programmieren hat man üblicherweise die Kontrolle über den Programmfluss und delegiert Aufgaben an Funktionen. In den objektorientierten Frameworks steuert das Framework den Ablauf und man selbst konfiguriert mehr oder wenig Dinge (zum Beispiel den Router) und definiert, was zu tun ist, wenn der Fluss an bestimmten Punkten vorbeikommt (unter anderem Controller-Actions, Views, Plugins). Dieser Kontrollverlust muss aber sein, damit man sich auf die wesentlichen Dinge konzentrieren kann.

Ich würde außerdem behaupten, dass Zend 2 nicht unbedingt ein Framework für Framework-Anfänger ist, selbst wenn sie schon objektorientiert programmiert haben.

Es ist schon wieder eine Weile her, seit ich einen Blick in Version 2 des Zend Frameworks geworfen habe. Mich hat bei diesem abgeschreckt, dass man recht viel konfigurieren muss und das in sehr verschachtelten Arrays, bei denen man nur Strings als Keys verwendet. Bei denen muss man selbst drauf achten, dass die Schreibweise stimmt, da hilft eine IDE mit Autovervollständigung wenig. Deswegen mag ich es nicht, wenn man Strings verwenden muss, um etwas zu steuern. Die hohe Komplexität der Arrays führt dazu, dass es sehr aufwendig ist, die Struktur zu erlernen und man wohl eher ständig im Handbuch nachschlagen muss.

Ein Vorteil wäre seine Bekanntheit und dass sich dann recht viele Leute drum kümmern und Erweiterungen beitragen. Es gibt aber auch genügend Alternativen zum Zend Framework. Das Yii-Framework machte auf mich einen recht ordentlichen Eindruck, aber auch da gab leider recht viele Key-Strings. Und die Datenkomponente war mir zu schwergewichtig. Sie arbeitet nach dem Muster Active Record, weswegen da jedes Datenobjekt viele Methoden zum Datenhandling mit sich führt. Die Kühe haben sozusagen ihre Fütterungs- und Melkmaschinen mit sich rumgetragen. Ich finde leichtgewichtige Datenobjekte besser, die lediglich ihre eigenen Methoden implementieren. Eine Kuh muss nur verdauen können und gelegentlich "Muh!" sagen. Das Melken und den Stall zu säubern ist des Bauers Aufgabe.

Vor kurzem lief mir Aura for PHP über den Weg. Gearbeitet hab ich damit noch nicht, aber das Handbuch zeigt ein recht aufgeräumtes System. Nunja, die Strings zum Konfigurieren sind auch da recht beliebt. Dafür kommt die Datenbank-Komponente recht einfach daher. Sie scheint mir lediglich ein SQL-Wrapper zu sein. Auch sieht mir der Rest des Systems so aus, als ob er sich vorwiegend auf seine Aufgabe als grundlegendes Framework konzentriert. Beim Yii gab es einige Kompoponenten, um recht schnell Daten in tabellarischer oder Einzelansichtsform ausgeben zu können. Solche sind bei Aura nicht (im Manual) zu finden. Ob ich sie vermissen würde, weiß ich noch nicht, ich hab noch kein Projekt mit Aura aufgesetzt, aber bei Gelegenheit werde ich das probieren.

dedlfix.

[heinetz]

Hallo,

Ich denke, du solltest nicht mit Zend anfangen, sondern erstmal mit dem objektorientierten Programmieren an sich.

Das finde ich auch. Es kommen da gleich zwei Dinge auf dich (heinetz) zu. Die ungewöhnte Objektorientierung ist das eine. Das andere ist die Umstellung der Herangehensweise an sich.

danke erstmal für eure Einschätzung, auf die ich schon recht viel Wert lege, zumal Ihr der selben Meinung seid. Ich möchte trotzdem darauf eingehen, wie ich überhaupt auf die Idee komme, dass es hilfreich sein bzw. überhaupt gehen könne, beides auf einmal zu lernen. Beides ist mir unbekannt und ich habe nur Ideen dazu, was sich dahinter verbirgt:

1. OOP dient dazu, Aufgaben zu kapseln.
2. Ein Framework besteht in erster Linie aus Konventionen.

In meinem Programmieralltag verbringe ich immer wieder sehr viel Zeit damit, meinen Code zu organisieren. Ich überlege mir immer wieder, bspw. wie Variablen und Funktionen benannt werden, damit der Code möglichst lesbar bleibt und verändere das während der Entwicklung. Wo bringe ich  welchen Code sinnvollerweise unter, welche Aufgabe wird an welcher Stelle im Code gelöst. Immer mit dem Ziel, die Übersichtlichkeit zu erhalten. Über die Jahre habe ich mir immer wieder meine eigenen Konventionen geschaffen und beim nächsten Projekt wieder verändert, weil die Anforderungen anders waren.

Während meiner Ausbildung habe ich ein bisschen OOP mit C++ und Java gelernt. Das ging nur ein paar Wochen und bei mir ist nichts mehr als die Idee hängengeblieben. Vor 4 oder 5 Jahren habe ich mich erstmals auf ein Framework eingelassen und nachdem ich jahrelang zu Fuss Javascript programmiert hatte jQuery lieben gelernt. Obwohl Javascript sich meiner Meinung nach objektbasiert statt objektorientiert nennt, entspricht ich die jQ-Plugin-Archtektur für mein Verständnis dem OOP-Gedanken.

Meine Entscheidung bzgl. Zend 2 hat damit zu tun, dass ich an zwei Fronten mit Leuten zusammenarbeite, die Zend einsetzen. Da wäre es nicht sinnvoll, mit etwas Anderem anzufangen, denn ich habe das Wort IndexController schonmal gehört ;)

Aber du musst das ausprobieren. Die Installation ist nicht schwer (Composer), und danach kann man schon direkt irgendwas hinfummeln und erste Erfolge haben. Kommst du dann mit konkreten Fragen, kannst du auch konkrete Antworten bekommen.

Vermutlich muss ich das. In den Tutorials, die ich mir angesehen hatte, wurden von der Zend Skeleton Application aus mit Composer das Framework und dann Module installiert ...

beste gruesse,
heinetz

[hotti]

Hallo Forum,

nachdem ich nun seit etwa 15 Jahren Websites mit PHP baue aber zum Einen immernoch nicht objektorientiert programmiere und zum Anderen immernoch dazu neige, alles immer wieder von Hand zu entwickeln, möchte ich mir an eine andere Herangehensweise angewöhnen. Mein Plan ist, mein nächstes Projekt mit Zend 2 zu realisieren. Meine Unsicherheit dabei ist, dass ich eigentlich garnicht weiss, was genau Zend 2 ist und wie ich am besten da einsteige.

Meine Herangehensweise wäre diese hier:
Zu prüfen, inwieweit OOP sich dafür eignet, bisherige Programmieraufgaben und auch zukünftige Projekte rationeller entwickeln zu können und darüber hinaus den Einsatz eines Frameworks in Erwägung zu ziehen. Das heißt insbesondere, dass ich selbst konkrete Vorstellungen davon habe, wie ein Framework beschaffen sein muss. Erst dann würde ich mich auf dem Framework-Market umschauen, ob da eines dabei ist, was meinen Erwartungen entspricht.

Wo fange ich am besten so an?

Mit OOP, aber nicht OOP zum Zelbstzweck sondern als Mittel zum Zweck. OOP ist sehr klischeebehaftet, OOP als die Lehre von Äpfeln, Birnen, Bienen und Blütenstaub ist allenfalls für den Biertisch tauglich. OOP ist eine praktische Angelegenheit, nimm Dir eines Deiner Scripts zur Hand, eines wo möglichst viele einzelne Variablen deklariert sind und überlege Dir beispielsweise, ob sich die Kapselung der einzelnen Variablen in _ein_ Datenobjekt lohnt. Daten wollen bewegt werden, welche Funktionen kämen dazu in Frage. Erst dann kommt die Klasse und ein geschielter Blick auf mögliche übergeordnete Instanzen. Dann kann aus dem Datenobjekt eine Instanz einer Klasse werden und die Funktionen den akademischen Grad 'Methode' bekommen.

Betrachte eine Website als Ansammlung von Datenobjekten. Objekte haben Attribute wie title, descr, body. Sie haben Gemeinsamkeiten wie z.B. einen <!doctype><html><head> [..] </head> sofern sie vom Content-Type: text/html sind. Das da [..] kann von Seite zu Seite abweichen: Andere links zu CSS-Dateien, JS-Dateien usw., was letztendlich über weitere Seiten-Attribute gesteuert werden kann.

Content-Management: Haben wir außer text/html auch andere Content-Types, welche auszuliefern sind? Und wieder eine Gemeinsamkeit: Egal ob jemand eine PDF oder ein HTML anfordert, in allen Fällen  ist es ein HTTP-Request auf eine eindeutige Webressource. Ob die Eindeutigkeit allein über den Path geregelt wird oder über angehängte Parameteter ist die nächste Frage: Das Routing und wie kompliziert wird das zu machen gedenken und welche Abhängigkeiten sich ergeben, wenn wir eine Klasse die sich um den Content der Response kümmert, im URL kodieren würden... solche Gedanken gehen in Richtung Skalierbarkeit, sei es bspw. drum eine Seite um ein Formular zu erweitern (neuer URL oder die an legacy URL gebundene Klasse erweitern oder eine andere Klasse).

Zu Letzterem ist hier ein schönes Beispiel: Ich habe sehr viele Seiten, die über class=DBFileResponse ausgeliefert werden, die Erweiterung DBFileResponse::downlink ermöglicht den Einbau eines Link zum Download über einen Platzhalter im Template und welcher Content-Type auf Klick dann ausgeliefert wird, darum kümmert sich die Klassenerweiterung anhand der für die Seite konfigurierten Attribute.

Eine andere Klassenerweiterung könnte z.B. den Einbau eines Formulars und die Kontrolle über Benutzereingaben übernehmen... soweit zum Thema Vererbung.

Und wie siehts mit dem Debugging aus, Fehlersuche, welche Klasse liefert eine verflixte Seite aus? Ich schaue in den Response-Header, ein ins HTML eingebauter Kommentar würds auch machen.

Testgetriebene Entwicklung: Wie teste ich automatisch, ob das Einloggen eines bestimmten Users geklappt hat? Etwa indem die ganze Seite nach bestimmten Text-Vorkommen geparst werden muss? Oder ob eine bestimmte CSS-Datei geladen wurde? Und was dann, wenn der Designer eine andere CSS-Datei einbaut, tja, dann geht der Test in die Hose; also doch besser die Prüfkriterien in x-headers senden, dann dauert der Test auch nicht die ganze Nacht und die Auswertung nicht den ganzen Vormittag...

Du stehst nicht am Anfang, baue auf Deine Erfahrung ;)

[heinetz]

hello,

Mit OOP, aber nicht OOP zum Zelbstzweck sondern als Mittel zum Zweck. OOP ist sehr klischeebehaftet, OOP als die Lehre von Äpfeln, Birnen, Bienen und Blütenstaub ist allenfalls für den Biertisch tauglich. OOP ist eine praktische Angelegenheit, nimm Dir eines Deiner Scripts zur Hand, eines wo möglichst viele einzelne Variablen deklariert sind und überlege Dir beispielsweise, ob sich die Kapselung der einzelnen Variablen in _ein_ Datenobjekt lohnt. Daten wollen bewegt werden, welche Funktionen kämen dazu in Frage. Erst dann kommt die Klasse und ein geschielter Blick auf mögliche übergeordnete Instanzen. Dann kann aus dem Datenobjekt eine Instanz einer Klasse werden und die Funktionen den akademischen Grad 'Methode' bekommen.

ja, meine Entscheidung für Zend hatte ich in meiner letzten Antwort erklärt: Ich habe in meinem direkten Umfeld einfach damit zu tun und würde deshalb erstmal nichts anderes verwenden wollen bzw. können.

Ich habe mich aber weiter damit auseinandergesetzt und stelle fest, dass ich tatsächlich recht schnell aus Modulen eine Zend-Beispielanwendung nachbauen kann, aber aufgeschmissen bin, sobald meine Anforderung zu speziell wird, denn ich weiss überhaupt nicht wo ich ansetzen muss

… also habe ich mich ein bisschen in OOP eingelesen. Die Idee von OOP war mir ja nicht neu, wie das Verhältnis zwischen Klasse, Objekt und Instanz ist und dass Funktionen darin Methoden und Variablen Eigenschaften heissen musste ich mir nur wieder in's Gedächtnis rufen. Private, protected oder public habe ich auch schonmal gehört und dann gab's Einiges, was ich nicht kannte.

Un nun möchte ich mein nächstes kleines Projekt mal objektorientiert denken, denn ich halte es für geeignet. Was mir dabei schwer fällt ist das Klassendesign (heisst das so?). Also die Überlegung was hier die Klassen sein sollen.

Ich würde mein Vorhaben an dieser Stelle vorstellen, wenn jemand Lust hat, mir bei der Modellierung zu helfen.

gruss,
heinetz

[hotti]

hi,

ja, meine Entscheidung für Zend hatte ich in meiner letzten Antwort erklärt: Ich habe in meinem direkten Umfeld einfach damit zu tun und würde deshalb erstmal nichts anderes verwenden wollen bzw. können.

Das ist ein guter Grund für eine Entscheidung.

Un nun möchte ich mein nächstes kleines Projekt mal objektorientiert denken, denn ich halte es für geeignet. Was mir dabei schwer fällt ist das Klassendesign (heisst das so?).

Würde ich auch so nennen.

Also die Überlegung was hier die Klassen sein sollen.
Ich würde mein Vorhaben an dieser Stelle vorstellen, wenn jemand Lust hat, mir bei der Modellierung zu helfen.

Klar, mach.

Aber eines verstehe ich nicht: 15 Jahre zu programmieren, ohne irgendwelche Berührungen mit OOP zu haben. Wird das in der PHP-Philosphie so strikt voneinander abgegrenzt? In Perl ist das anders, spätestens dann, wenn ein Modul für eine bestimmte Aufgabe von CPAN geladen wird, nehmen wir z.B. Net::FTP, erstellt der Anwender des Moduls ein (FTP)-Objekt und bewegt damit Dateien von a nach b. Oder holt mit einem Mail::POP3-Objekt seine Mails vom POP3.

Viele Grüße ;)

[Camping_RIDER]

Aloha ;)

Aber eines verstehe ich nicht: 15 Jahre zu programmieren, ohne irgendwelche Berührungen mit OOP zu haben. Wird das in der PHP-Philosphie so strikt voneinander abgegrenzt? In Perl ist das anders, spätestens dann, wenn ein Modul für eine bestimmte Aufgabe von CPAN geladen wird, nehmen wir z.B. Net::FTP, erstellt der Anwender des Moduls ein (FTP)-Objekt und bewegt damit Dateien von a nach b. Oder holt mit einem Mail::POP3-Objekt seine Mails vom POP3.

Tja, das ist so ne Sache. PHP kann inzwischen ja OOP. (Auch schon ein bisschen länger, aber definitiv nicht schon immer). Trotzdem fühlt sich PHP vom gesamten Aufbau und seiner eigenen Struktur her sehr prozedural an. Ich ertappe mich selbst dabei, wie ich (der eigentlich OOP kann) in PHP immer wieder in alte Muster zurückfalle - einfach weil prozedurale Programmierung irgendwie aus der Sprache heraus unbewusst ein stimmigeres Gefühl beim Programmieren mit PHP erzeugt. Zumindest bei mir ist das so.

Es hängt auch ein wenig mit der Syntax zusammen... Mir kommt die PHP-Syntax für OOP immer sehr übetrieben aufgeblasen vor. Da kommt zumindest für mich keine so rechte Motivation auf, objektorientiert zu arbeiten. In JavaScript beispielsweise ist das vollkommen anders. Da wird man ja schon überall wo man schaut mit der Nase auf die OOP hingestoßen. OOP und PHP ist imho ein schwieriges Thema.

Es wird von offizieller Seite aber nachgebessert, neue Funktionalitäten kommen inzwischen imho immer mehr als Memberfunktionen abstrakter oder nicht so abstrakter Objekte auf, und tendenziell nicht mehr wie früher, als globale Funktion mit elendig lang-ätzendem Namen. Je mehr der Sprachstandard OOP nutzt, umso leichter wird es auch in PHP werden, die prozeduralen Programmierfähigkeiten einzumotten.

Grüße,

RIDER

[hotti]

Moin,

Es hängt auch ein wenig mit der Syntax zusammen... Mir kommt die PHP-Syntax für OOP immer sehr übetrieben aufgeblasen vor. Da kommt zumindest für mich keine so rechte Motivation auf, objektorientiert zu arbeiten. In JavaScript beispielsweise ist das vollkommen anders. Da wird man ja schon überall wo man schaut mit der Nase auf die OOP hingestoßen. OOP und PHP ist imho ein schwieriges Thema.

Ja, dieses Entweder OOP oder nicht OOP (prozedural) kann ich z.T. nachvollziehen, wenn ich bestimmte Teile der PL-Architektur mit Perl vergleiche.

Was in Perl z.B. möglich ist: Vom prozeduralen Aufbau eines Scripts zu einem objektorientierten Aufbau zu migrieren, Schritt für Schritt. In Perl gibt es immer eine Package namens 'main' (die erbt z.B. von class UNIVERSAL). Jetzt könntest Du z.B. alle Variablen der package 'main' in einer einzigen Referenz {att => 'val'} zusammenfassen, das wäre zunächst ein Datenobjekt. Im nächsten Schritt wird dieses Datenobjekt mit dem Namen einer Klasse gesegnet, z.B. mit dem Namen der Klasse 'main':

my $main = bless{}, 'main';

und aus dem Aufruf von Funktionen

foo(); # entspricht main::foo();

werden Aufrufe von Methoden:

$main->foo();

wobei die Instanz der Klasse 'main' (das $main-Objekt) als erstes Argument übergeben wird. Oft erübrigen sich damit weitere Argumente, denn das $main-Objekt (hier nur als Beispiel für eine Instanz) hat ja Attribute, die womöglich auch an anderer Stelle (andere Methode) gebraucht werden. In den Attributen können weitere Instanzen (anderer Klassen) untergebracht sein, womit sich bestimmte Aufgaben als Methoden delegieren lassen:

  
my $main = bless{  
  FTP => Net::FTP->new(),  
  POP => Mail::POP3->new(),  
  CGI => CGI->new(), # usw.  
}, 'main';  

Was in vielen Fällen eine zweckmäßige Alternative ist: Anstelle einer Mehrfach-Vererbung (main erbt von CGI, Net::FTP, Mail::POP3, ...) wird einfach nur delegiert, ohne ein vogelwildes Klassendesign hinzuwerfen und sich dann überlegen zu müssen, wie die Klassen zusammenwirken sollen, so dass nicht mit grundsätzlichen Regeln der OOP gebrochen wird.

In Perl ist also eine Instanz einer Klasse lediglich eine Referenz die weiß zu welcher Klasse sie gehört. Das hat sehr praktische Konsequenzen zur Folge, die ich in PHP vermisse. Konsequenzen, die für eine wartbare Strukturierung von Code essentiell (lebensnotwendig) sind, z.B. eine saubere Gliederung/Trennung der Namespaces, was mit hunderten Built-in-Funktionen (alle im gleichen Scope) schwierig wird (Btw., in Perl gibt es nur so um die 100 Built-in-Funktionen).

Letztendlich sehe ich das Ziel einer objektorientierten Herangehensweise darin, komplexe Zusammenhänge auf einem einfachen Code abzubilden und nicht noch komplizierter zu machen.

Mehr dazu auf meinem Blog ;)

[M.]

Mahlzeit,

In JavaScript beispielsweise ist das vollkommen anders. Da wird man ja schon überall wo man schaut mit der Nase auf die OOP hingestoßen. OOP und PHP ist imho ein schwieriges Thema.

Und das sehe ich komplett gegenteilig. Grad bei Javascript muss ich mich zwingen um OOP zu programmieren und OOP in Perl find ich Horror.
Alles Gewohnheit, wie ich finde. ABer als ich Perl und Javascript gelernt hab, gabs da noch keine Objekte (oder zumindest kann ich mich daran nicht erinnern)

[heinetz]

hello,

Klar, mach.

OK, danke für das Angebot!

Die Ausgangssituation ist folgende:
-----------------------------------
Ein Unternehmen handelt international mit Autolackiererbedarf. Das umfasst, sagen wir 1000 Artikel wie Lacke, Primer, Spachtelmasse, Klebeband usw. Für jeden dieser Artikel gibt ein sog. technisches Dokument in unterschiedlichen Sprachen. So ein technisches Merkblatt enthält Standard-Eigenschaften, wie Artikel-Nummer, Produkt-Name usw., die jeder Artikel hat. So ein technisches Merkblatt kann aber auch artikelspezifische Eigenschaften enthalten. Bspw. hat ein Klebeband möglicherweise eine Breite, wohingegen ein Lack eher die Eigenschaft "Ablüftzeit" hat.

Dafür gibt es eine kleine Web-Anwendung:
----------------------------------------
Es gibt also ein nicht öffentliches Frontend, über das diese technischen Dokumente (=Datensätze) von verschiedenen Benutzern erstellt und verwaltet werden. Das besteht aus einer Übersicht, in der alle Datensätze aufgelistet werden, einer Detailansicht, in der der in der Übersicht ausgewählte Datensatz mit all seinen Eigenschaften dargestellt bzw. editiert (oder gelöscht) wird, was bedeutet, die Werte der Standard-Eigenschaften anzupassen oder individuelle Eigenschaften hinzuzufügen und deren Werte festzulegen. Die individuellen Eigenschaften können ausserdem in ihrer dargestellten Reihenfolge geändert und natürlich gelöscht werden.
Für das Anlegen neuer Datensätze wird die selbe Maske verwendet.

Bis zu dem Punkt hat das Unternehmen nun die ganzen Artikel in irgendeiner Datenbank und kann sie verwalten, was ja noch keinen wirklichen Mehrwert darstellt …

Die Funktionalitäten:

1. Generate PDF
Dazu muss ich glaube ich nichts sagen …

2. Duplicate Doc for Translation
Die Datensätze haben u.a. auch eine Eigenschaft "Sprache", die sich per Dropdown festlegen lässt. In meinen Beispiel-JPG sieht man einen Datensatz, der mit der Eigenschaft "deutsch" angelegt wurde und nun wird dieses technische Dokument in finnisch benötigt. Hier kommen die Benutzerrollen in's Spiel. Es gibt genau einen Benutzeraccount für den finnischen Übersetzer. Weil der deutsch kann ruft er die Detailansicht des deutschen Datensatzes auf und "dupliziert das Doc for Translationen". Danach werden die Label der Standard-Eigenschaften in finnisch angezeigt, die deutschen Werte in den Formularfeldern tauscht er gegen deren finnische Übersetzung aus.

Das Problem:
------------
Die Anwendung hat vor Jahren mal ein Praktikant in PHP4 objektorientiert programmiert und sie soll auf einem Server laufen, der PHP4 nicht mehr unterstützt. Unter PHP5 läuft die Anwendung nun nicht mehr und hatte zunächst versucht, das zu debuggen, in der Auseinandersetzung hier festgestellt, das sich PHP4 und PHP5 grundsätzlich unterscheiden und es sinnvoll ist, das ganze neu zu schreiben.

Meine Lösung:
-------------
… würde ich relativ schnell prozedural umsetzen, habe aber die Zeit mich an dem Beispiel mit OOP zu probieren. Ich fange nicht bei NULL an. Die Daten sollen natürlich erhalten bleiben, d.h. die DB-Struktur/-Inhalte würde ich so übernehmen müssen. Das Nutzerrollenkonzept will ich etwas anders umsetzen : Ein Benutzer, der einen Datensatz anlegt, ist dessen Besitzer und nur er kann ihn editieren. Jeder Benutzer kann neue Datensätze in jeder Sprache entweder leer oder aus einem Duplikat anlegen.

Und konkret?
------------
Mein Bauchgefühl sagt mir es gibt zuerstmal eine Klasse 'technicalDocument' oder um nicht soviel tippen zu müssen 'tecDoc'. Im Code der Detailansicht würde also in etwa folgendes stehen:

include "path/to/file/tecdoc.class.php";  
$doc = new tecDoc(intval($_GET['id']));  
$doc -> displayForm();

Kann man so anfangen?

beste gruesse,
heinetz

[M.]

Mahlzeit,

include "path/to/file/tecdoc.class.php";

$doc = new tecDoc(intval($_GET['id']));
$doc -> displayForm();

  
Ich glaub, Objekte müssen laut Coding-Standard in Zend mit nem Grossbuchstaben beginnen (ohne Gewähr).  
Was ich sagen will, wenn schon Zend, dann auch gleich den kompletten Coding Standard mitnehmen, incl. Namespaces etc.  
  
Ansonsten kannst du das natürlich so machen  

-- 
eigentlich ist mir bewusst, dass ich hin und wieder einfach mal die Klappe halten sollte. Doch genau in den unpassendsten Momenten erwische ich mich dabei, wie ich dennoch etwas sage ...

[heinetz]

hello,

include "path/to/file/tecdoc.class.php";

$doc = new tecDoc(intval($_GET['id']));
$doc -> displayForm();

>   
> Ich glaub, Objekte müssen laut Coding-Standard in Zend mit nem Grossbuchstaben beginnen (ohne Gewähr).  
> Was ich sagen will, wenn schon Zend, dann auch gleich den kompletten Coding Standard mitnehmen, incl. Namespaces etc.  
>   
> Ansonsten kannst du das natürlich so machen  
  
Ich hatte mich ja nun erstmal von Zend verabschiedet um mich unabhängig vom Framework erstmal mit OOP ansich auseinanderzusetzen. Trotzdem ist der Einwurf sehr interessant und wirft Fragen auf:  
  
- Macht es Sinn, sich unabhängig von Zend diesen Coding-Standard einzuhalten?  
- Steht dieser Coding-Standard im Widerspruch zu anderen Frameworks?  
- Gibt es auch einen unabhängigen Coding-Standard?  
  
gruss,  
heinetz

[dedlfix]

Tach!

Ich hatte mich ja nun erstmal von Zend verabschiedet um mich unabhängig vom Framework erstmal mit OOP ansich auseinanderzusetzen. Trotzdem ist der Einwurf sehr interessant und wirft Fragen auf:

• Macht es Sinn, sich unabhängig von Zend diesen Coding-Standard einzuhalten?

Ja, meistens. Für Dinge wie Klammernsetzung und andere Optik musst du den fremden Coding-Standard nicht berücksichtigen, wenn du nicht magst. Aber siehe dritte Antwort.

• Steht dieser Coding-Standard im Widerspruch zu anderen Frameworks?

In Details vielleicht.

• Gibt es auch einen unabhängigen Coding-Standard?

Es gibt die PSR-Standards. Da ist unter anderem ein Autoloading definiert. Und für den braucht es eine einheitliche Benennung deiner Klassen. Für solche Dinge ist es nützlich, den Coding-Standard einzuhalten.

dedlfix.

[heinetz]

hello,

Ich hatte mich ja nun erstmal von Zend verabschiedet um mich unabhängig vom Framework erstmal mit OOP ansich auseinanderzusetzen. Trotzdem ist der Einwurf sehr interessant und wirft Fragen auf:

• Macht es Sinn, sich unabhängig von Zend diesen Coding-Standard einzuhalten?

Ja, meistens. Für Dinge wie Klammernsetzung und andere Optik musst du den fremden Coding-Standard nicht berücksichtigen, wenn du nicht magst. Aber siehe dritte Antwort.

gut, dann versuche ich mich an die Standards zu halten und definiere folgendes

index.php?id=12345

include "path/to/file/tecdoc.class.php";  
$doc = new TecDoc(intval($_GET['id']));  
$doc -> displayForm();

Auf meiner Seite Detailansicht steht nun also  dieser Code. Die Methode displayForm() sollte demnach einen String "<form …. </form>" ausgeben.

Der String enhält generell diverse input-Elemente. Also sich wiederholende Teile mit individuellen Ausprägungen (Attributen). Dafür macht also eine eigene Funktion Sinn. Ich würde denken, diese Funktion ist neben displayForm() eine weitere Methode input() der Klasse TecDoc. Die Methode input()  wird (erstmal) nur innerhalb der Klasse TecDoc angesprochen. Daher wäre sie im Gegensatz zu public displayForm() private.

path/to/file/tecdoc.class.php

/**  
* Meine prima TecDoc-Klasse  
*/  
class TecDoc  
{  
  /**  
  * Meine Methode displayForm gibt einen String "<form…</form>" aus  
  */  
  public function displayForm()  
  {  
    ...  
  }  
  
  /**  
  * Meine Methode input gibt einen String "<input…</input>" zurück  
  */  
  private function input()  
  {  
    ...  
  }  
}

Und hier kommt mein 1. Problem!
-------------------------------
Das Objekt $doc hatte ich mit einem Parameter initialisiert(?). In jQuery bin ich gewohnt, eine Instanz mit Parametern zu bilden. In den PHP5-Beispielen, die ich mir so ansehe, wird da kein Parameter übergeben. Um das Ganze ohne Parameter-Übergabe beim initialisiert(?) zu regeln könnte man das so lösen:

public $id = intval(GET['id']);

Aber macht man das so?

beste gruesse,
heinetz

[dedlfix]

Tach!

gut, dann versuche ich mich an die Standards zu halten und definiere folgendes

index.php?id=12345

include "path/to/file/tecdoc.class.php";

$doc = new TecDoc(intval($_GET['id']));
$doc -> displayForm();

  
Wenn du aber so herangehst, ignorierst du das MVC-Muster und die Möglichkeiten des Zend-Framework. URL-Parameter wertet man nicht direkt aus, die extrahiert der Router aus dem Request und stellt sie bereits fertig zur Verfügung. Gegebenenfalls musst du noch eine Routing-Regel konfigurieren, wenn du nicht die per Default vorgesehene URL-Struktur verwenden magst/kannst.  
  
Es kann zwar Klassen geben, die eine HTML-Ausgabe erzeugen, aber das ist eigentlich Aufgabe der View (das V in MVC). Wenn die Ausgabe komplexer wird, kann die View sich eines Helpers bedienen, um zum Beispiel eine Tabelle zu erstellen oder ein Formular. Der wiederum bekommt seine Daten direkt von der View. Wenn das eine Nutzereingabe ist, geht die den Weg vom Router über den Controller zur View. Allerdings ist das selten so der Fall. Eher fragt der Controller ein Model, um die gewünschten Daten zu beschaffen (oder gemäß der Geschäftslogik zu verarbeiten und zu speichern). Der Controller selbst arbeitet idealerweise nicht, der delegiert nur.  
  

> Das Objekt $doc hatte ich mit einem Parameter initialisiert(?). In jQuery bin ich gewohnt, eine Instanz mit Parametern zu bilden. In den PHP5-Beispielen, die ich mir so ansehe, wird da kein Parameter übergeben. Um das Ganze ohne Parameter-Übergabe beim initialisiert(?) zu regeln könnte man das so lösen:  
> `public $id = intval(GET['id']);`{:.language-php}  
> Aber macht man das so?  
  
Mal unabhängig vom ZF geantwortet, es gibt Konstruktor-Funktionen (landläufig auch nur als Konstruktor bezeichnet), die beim Instantiieren aufgerufen werden, wenn sie vorhanden sind. Die können auch Parameter entgegennehmen.  
  
  
dedlfix.

[heinetz]

hello,

Wenn du aber so herangehst, ignorierst du das MVC-Muster und die Möglichkeiten des Zend-Framework. URL-Parameter wertet man nicht direkt aus, die extrahiert der Router aus dem Request und stellt sie bereits fertig zur Verfügung. Gegebenenfalls musst du noch eine Routing-Regel konfigurieren, wenn du nicht die per Default vorgesehene URL-Struktur verwenden magst/kannst.

gut, ich bemerke, dass mir noch nicht ganz klar zu sein scheint, was das erste Ziel meiner Übung ist. Ich hatte ursprünglich den Plan, PHP5 OOP und Zend mit einem Anlauf zu lernen. Davon hattet Ihr abgeraten und ich dachte, nun ist meine Aufgabe erstmal, das was ich sonst prozedural coden würde objektorientiert zu machen, um mich mit OOP vertraut zu machen.

Nun bin ich mir aber selbst nicht mehr sicher, was der beste Fahrplan ist ;(

gruss,
heinetz

[dedlfix]

Tach!

gut, ich bemerke, dass mir noch nicht ganz klar zu sein scheint, was das erste Ziel meiner Übung ist. Ich hatte ursprünglich den Plan, PHP5 OOP und Zend mit einem Anlauf zu lernen. Davon hattet Ihr abgeraten und ich dachte, nun ist meine Aufgabe erstmal, das was ich sonst prozedural coden würde objektorientiert zu machen, um mich mit OOP vertraut zu machen.

Auch wenn du ohne das ZF nur mit OOP arbeiten möchtest, ist es sinnvoll, zumindest das EVA-Prinzip zu beachten. Das heißt, dass du Zuständigkeiten verteilst und nicht, wie mir scheint, die Seite, die vorher in einer Datei prozedural abgearbeitet wurde, nun lediglich ein Objekt geworden ist.

Nun bin ich mir aber selbst nicht mehr sicher, was der beste Fahrplan ist ;(

Vielleicht so: Erstmal OOP und speziell die Möglichkeiten PHPs kennenlernen, insbesondere auch den Teil Magische Methoden nicht außer Acht lassen. Danach Patterns kennenlernen, vor allem das MVC-Muster. Da gibt es auch allgemein gehaltene Einführungen, zum Beispiel jene: http://tutorials.lemme.at/mvc-mit-php/ (Das war der erstbeste Link, ich hab keine Qualitätskontrolle vorgenommen.) Und dann mal schauen, wie es das große ZF macht.

dedlfix.

[heinetz]

hello,

Auch wenn du ohne das ZF nur mit OOP arbeiten möchtest, ist es sinnvoll, zumindest das EVA-Prinzip zu beachten. Das heißt, dass du Zuständigkeiten verteilst und nicht, wie mir scheint, die Seite, die vorher in einer Datei prozedural abgearbeitet wurde, nun lediglich ein Objekt geworden ist.

ganz genau so wie es Dir scheint ist es auch!

Ich habe in meinem Beispiel damit angefangen, das was ich vorher prozedural gemacht bzw. gedacht hätte als Objekt zu definieren, ohne wirkliches Ziel und ohne dass sich mir bis zu dem Zeitpunkt Vorteile erschlossen hätten.

Vielleicht so: Erstmal OOP und speziell die Möglichkeiten PHPs kennenlernen, insbesondere auch den Teil Magische Methoden nicht außer Acht lassen. Danach Patterns kennenlernen, vor allem das MVC-Muster. Da gibt es auch allgemein gehaltene Einführungen, zum Beispiel jene: http://tutorials.lemme.at/mvc-mit-php/ (Das war der erstbeste Link, ich hab keine Qualitätskontrolle vorgenommen.) Und dann mal schauen, wie es das große ZF macht.

Ich glaube das Problem besteht im "Kennenlernen". Eine Doku durchzulesen ist wie ein Lexikon durchzulesen.

Vielleicht so?:

1. Die Aufgabe reduzieren : Daten nur ausgeben nicht verändern
a) MVC als Pattern festlegen.
b) Die Aufgabe inhaltlich in Teilaufgaben splitten und auf M V und C verteilen.
c) Die Teilaufgaben objektorientiert mit PHP lösen

2. Die Aufgabe erweitern und wieder … a,b,c

… und so weiter.

Und am Ende in Zend 2 übertragen.

Und auch hier stellt sich die Frage ab welchem Punkt kommt Zend in's Spiel. Zu früh könnte bedeuten, dass ich die Orientierung verliere (das passiert nicht, wenn ich mir vorn vornherein angewöhne Klassennamen mit einem Grossbuchstaben am Anfang zu benennen). Zu spät könnte möglicherweise bedeuten, dass ich am Anfang in die falsche Richtung gearbeitet habe. Das heisst nicht, dass ich mich vor der Arbeit scheue, Dinge nochmal zu machen oder umsonst gemacht zu haben, sondern dass Zend logisch zu *anders* ist. Das kann ich aber nicht beurteilen und bin auf eure Einwürfe angewiesen.

Ich habe mittlerweile das hier gefunden. Meine Aufgabe reduziert liesse sich meiner Meinung nach ganz gut darauf übertragen:

• Es gibt drei Datensätze
• Es gibt eine Übersicht, in der die Titel aller Datensätze aufgelistet werden.
• Es gibt eine Detailansicht, in der ein konkreter Datensatz angezeigt wird, nachdem er in der Übersicht ausgewählt wurde.

Klingt das vernünftig?

gruss,
heinetz

… das ist ja abgefahren! In der Vorschau fällt mir gerade auf, dass die Links identisch sind

[dedlfix]

Tach!

Und auch hier stellt sich die Frage ab welchem Punkt kommt Zend in's Spiel. Zu früh könnte bedeuten, dass ich die Orientierung verliere (das passiert nicht, wenn ich mir vorn vornherein angewöhne Klassennamen mit einem Grossbuchstaben am Anfang zu benennen). Zu spät könnte möglicherweise bedeuten, dass ich am Anfang in die falsche Richtung gearbeitet habe.

Ja, so ist das meistens und daran fidne zumindest ich nichts wirklich schlimmes dran. Fehler gehören zum Erfahrungsschatz dazu. Man muss sie kennen, damit man weiß, warum man etwas auf eine bestimmte Art und Weise nicht macht sondern auf eine andere.

Das heisst nicht, dass ich mich vor der Arbeit scheue, Dinge nochmal zu machen oder umsonst gemacht zu haben, sondern dass Zend logisch zu *anders* ist. Das kann ich aber nicht beurteilen und bin auf eure Einwürfe angewiesen.

Grundlegend hält es sich schon an das MVC-Prinzip. Das ist auch das Haupt-Merkmal des Systems. Aber das allein reicht noch nicht, um eine Anwendung zu stellen. Das Model muss seine Daten persistieren, dazu bedient es sich einer Datenbankabstraktion. Aber auch Webservices können angesprochen werden, wozu jedoch wieder andere Komponenten Verwendung finden. Und so weiter und so fort. Aber für genauere Auskünfte zum ZF kann ich dir keine geben.

Ich habe mittlerweile das hier gefunden. Meine Aufgabe reduziert liesse sich meiner Meinung nach ganz gut darauf übertragen:

• Es gibt drei Datensätze
• Es gibt eine Übersicht, in der die Titel aller Datensätze aufgelistet werden.
• Es gibt eine Detailansicht, in der ein konkreter Datensatz angezeigt wird, nachdem er in der Übersicht ausgewählt wurde.
  Klingt das vernünftig?

Klingt erstmal gut.

… das ist ja abgefahren! In der Vorschau fällt mir gerade auf, dass die Links identisch sind

Es war der erste den ich fand und du anscheinend auch.

dedlfix.

[heinetz]

hello,

Aber eines verstehe ich nicht: 15 Jahre zu programmieren, ohne irgendwelche Berührungen mit OOP zu haben. Wird das in der PHP-Philosphie so strikt voneinander abgegrenzt?

Das stimmt nicht ganz. Ich habe in diesen 15 Jahren sehr wohl schon Berührungen mit OOP gehabt. Ich habe vor 15 Jahren tatsächlich eine Ausbildung als Fachinformatiker für Softwareentwicklung gemacht. Ich bin mit NULL IT-Kenntnissen da reingegangen und das heisst wirklich nie zuvor gebotet. Programmieren mit Struktogrammen und auf Papier lag mir aber sehr gut. Wir haben ein bisschen prozedural mit C angefangen und dann OOP mit C++ und Java weitergemacht. Aber eben alles sehr theoretisch und mit ein paar Übungsaufgaben. Dann bin ich aber sofort in einer Internetagentur gelandet und habe HTML4, Javascript und PHP3 gemacht. Weil JS dem, was ich in meiner Ausbildung gelernt hatte am nächsten kam (ich fand den OOP-Gedanken nämlich ganz gut;) und weil ich mit JS irgendwelcher Layer bewegen konnte, habe ich mich eigentlich immer lieber damit auseinandergesetzt und alles von Hand gebastelt. Nur dass man das eben damals nicht viel brauchte, weil man eben nur Layer ein- und ausblenden oder hin- und herbewegen konnte. Vor ein paar Jahren habe ich dann jQuery für mich entdeckt. Auch wenn JS streng genommen nicht OOP ist, entspricht meine gedankliche Herangehensweise bspw. beim Entwickeln eine jQ-Plugins der, die ich in meiner Ausbildung gelernt hatte.

Mit PHP fällt mir das gedanklich schwerer und ich glaube ich weiss jetzt auch warum!

Aber das klärt sich ja jetzt vielleicht am praktischen Beispiel.

gruss,
heinetz

[tami]

hi heinetz,

oder einfach mal ausprobieren (was Sven sagt, stimmt natürlich ...)

http://forum.de.selfhtml.org/archiv/2014/5/t217437/#m1493705

es ist _auch_ ein baukastenprinzip ... (wie PEAR).

tami

[tami]

hi tami,

https://forum.selfhtml.org/?t=218910&m=1510890

mfg

tami