nicht angemeldet dedlfix
Camping_RIDER
Camping_RIDER
Der Martin
dedlfix
dedlfix
Camping_RIDER
Camping_RIDER
dedlfix
Hallo nochmal,
Ich hab Fragen zu PHP Projekten.
Wo ist es sinnvoll in einem komplexeren php-projekt welche php Dateien wo im MVC-Modell reinzupacken. .lib.php, .inc.php in model?
Wie ist HTML in einer PHP-Datei aufgeteilt? Strikt getrennt oder wie beim Eingabefomular beide zusammen in einer Datei?
Ich möchte mich weniger blamieren, deswegen Frage ich.
Grüße, MB
Moin!
- Wo ist es sinnvoll in einem komplexeren php-projekt welche php Dateien wo im MVC-Modell reinzupacken. .lib.php, .inc.php in model?
Libarys (Bibliotheken) enthalten Programmfunktionen, die mit dem "Endprogramm" nicht unmittelbar zu tun haben und in ganz anderen Programmen Verwendung finden können (nehmen wir mal als Beispiel eine Funktion, die prüft, ob eine IP-Adresse zu einem Netzwerk gehört.) Diese werden allerdings auch includiert.
Wenn Du da schon trennen willst, dann verwende "*.inc.php" für echte Inkludes, z.b. wenn Du in einer config.php Daten setzt. Allerdings tragen diese dann durchaus zum Programmablauf bei. Die View-Schicht ist alles, was aus den Daten das dem Webserver zu übergebende HTML (und/oder CSS/JS) erzeugt (Falls PHP als Templatesprache für die Webseitenerzeugung genutzt wird, was längst nicht immer der Fall ist.
- Wie ist HTML in einer PHP-Datei aufgeteilt? Strikt getrennt oder wie beim Eingabefomular beide zusammen in einer Datei?
Seit wann sind HTML-Formular und verarbeitendes PHP in einer Datei? Das mag für "Affenskripte" zutreffen aber es spricht vieles dafür, das nicht so zu machen. Gerade MVC.
Ich möchte mich weniger blamieren, deswegen Frage ich.
MVC ist derzeit ein Buzzword. Was Model (Daten), View (Präsentation) und C (Kontroller) sind unterscheidet sich schon mal je nach Perspektive. Das lässt sich also niemals so genau bestimmen. So lange Du aus PHP-Sicht darauf schaust kannst Du auch sagen: Daten sind, na die Daten aus Dateien, Datenbanken oder Geräten. Die sind also zugleich das Model. Die View ist das Erzeugen von HTML aus Daten und Templates. Der Controller ist jegliche Verarbeitung von Daten oder Ausgaben zu den Daten, die dann von der View verarbeitet werden.
Aus Sicht des Browsers ist dann die Webseite mit allem Inhalt (HTML, CSS, JS) erstmal "die Daten". Also Model. Controller ist alles, was die Webseite vor der Darstellung verarbeitet (und bei nicht validen Seiten spekuliert was der "Webdesigner" eigentlich will) und zur View zählen dann CSS aber auch Widgets wie zB. die Vorlagen für die Anzeige von Formularelementen.
Aus Sicht von Javascript ist das DOM der Webseite und mit "AJAX" übertragene bzw. in Formulare eingegebene, aber auch der Inhalt hart codierter Variablen "Daten". Die View ist das, was nach deren Verarbeitung präsentiert wird, regelmäßig also wieder DOM.
Buzzwort: Joomla versucht sich in MVC. Davon sollte man aber eher nichts lernen. Was nützt all die schöne Theorie, wenn bei der Umsetzung Mist gemacht wird.
Buzzwort II: Es macht keinen Sinn Kleinigkeiten in ein MVC-Muster zu pressen: "Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht" - das ist bei Kleinigkeiten höchst kontraproduktiv.
Jörg Reinholz
Hallo Jörg,
Libarys (Bibliotheken) enthalten Programmfunktionen, die mit dem "Endprogramm" nicht unmittelbar zu tun haben und in ganz anderen Programmen Verwendung finden können (nehmen wir mal als Beispiel eine Funktion, die prüft, ob eine IP-Adresse zu einem Netzwerk gehört.) Diese werden allerdings auch includiert.
deswegen meine Frage. Danke Dir schon mal
Seit wann sind HTML-Formular und verarbeitendes PHP in einer Datei? Das mag für "Affenskripte" zutreffen aber es spricht vieles dafür, das nicht so zu machen. Gerade MVC.
Thomas Thies von Galileo hat das geraten. Für mich auch nicht nachvollziehbar
Buzzwort: Joomla versucht sich in MVC. Davon sollte man aber eher nichts lernen. Was nützt all die schöne Theorie, wenn bei der Umsetzung Mist gemacht wird.
Joomla habe ich ne einführung bekommen neben bei.
Buzzwort II: Es macht keinen Sinn Kleinigkeiten in ein MVC-Muster zu pressen:
Das ist mir bewusst
das ist bei Kleinigkeiten höchst kontraproduktiv.
Zur Übung reichts oder? Und danke für deine Umfangreiche AW
Grüße MB
Tach!
- Wo ist es sinnvoll in einem komplexeren php-projekt welche php Dateien wo im MVC-Modell reinzupacken. .lib.php, .inc.php in model?
Wenn du dir nicht gerade ein MVC-Framework selbst stricken möchtest, solltest du in die Dokumentation des verwendeten Systems schauen, denn meist gibt es Konventionen, die einem eine Menge Inkludiererei sparen, weil es einen Auto-Loader gibt, der anhand des Klassennamens auf den Dateinamen schließt (und üblicherweise nur ein einfaches .php anhängt).
- Wie ist HTML in einer PHP-Datei aufgeteilt? Strikt getrennt oder wie beim Eingabefomular beide zusammen in einer Datei?
So wie man es braucht. Auch da gibt die Dokumentation des verwendeten Systems üblicherweise Vorschläge.
dedlfix.
hi,
Ich hab Fragen zu PHP Projekten.
Ich schreib Dir mal, wie ich das in Perl mache, vielleicht kannst Du dem ja was abgewinnen:
- Wo ist es sinnvoll in einem komplexeren php-projekt welche php Dateien wo im MVC-Modell reinzupacken. .lib.php, .inc.php in model?
Ich setze einmal den @INC-Pfad und dann werden Methoden, die ggf. weitere Klassen inkludieren, automatisch geladen (Factory).
Per externer Konfiguration kann ich URLs ein beliebiges Interface zuweisen, sei es um Platzhalter zu beleben oder die ganze Seite interaktiv zu machen.
- Wie ist HTML in einer PHP-Datei aufgeteilt? Strikt getrennt oder wie beim Eingabefomular beide zusammen in einer Datei?
Sowohl als auch, das regelt die View-Class, da kann ich festlegen aus welcher Quelle das Template geladen wird und das kann auch unterhalb eines Token innerhalb derselben Datei liegen. In Perlmodulen ist für sowas unterhalb __ DATA __ ein idealer Platz für Templates.
Mit Hilfe einer geeigneten Boundary unterteile ich ggf. ein Template in mehrere Templates und kann mir das für die jeweilige Anwendung entsprechend zusammenbauen wobei dafür nicht extra weitere Dateien geladen werden müssen sondern nur Eine.
Code mit HTML zu mischen ist keine gute Idee, da geht schnell die Übersicht flöten. So gab es auch in EmbPerl Versuche in diese Richtung, die sich jedoch nicht weiter verbreitet haben. Eine einfache Template-Engine die Skalare und Arrays rendern kann, reicht vollkommen. Bilde die Progammlogik NICHT im Template ab.
Leider können die meisten mir bekannten Templateengines viel zu viel des Guten, bremsen am Ende alles aus und machen jegliche Performance-Optimierung zunichte. pl
Moin!
Ich beklage mich mal über den Missbrauch der Bewertungsfunktion. Hier spielen wohl eher persönliche Motive eine Rolle als die Vermutung, dass Beitrag von pl (der zugegebenermaßen an der Frage irgendwie vorbeigeht) grob unsinnig oder wirklich kritikwürdig wäre.
Dementsprechend fehlt es dann auch erwartungsgemäß an einer Begründung.
Jörg Reinholz
Aloha ;)
Ich beklage mich mal über den Missbrauch der Bewertungsfunktion. Hier spielen wohl eher persönliche Motive eine Rolle als die Vermutung, dass Beitrag von pl (der zugegebenermaßen an der Frage irgendwie vorbeigeht) grob unsinnig wäre.
Du interpretierst in die Bewertungsfunktion etwas hinein, was darin nicht enthalten ist. Seit CForum 4 ist die Bewertung kein Ausdruck für "Fachlich hilfreich" mehr (was einen Anspruch auf Objektivität erhebt), sondern mehr ein Ausdruck dafür, ob ein Beitrag subjektiv empfunden an einer bestimmten Stelle angebracht ist oder nicht.
Wir hatten diese Diskussion seit der Umstellung auf die neue Forenversion (inzwischen auch schon ein halbes Jahr her) desöfteren; die verschiedenen Diskussionen (mit immer gleichem Ausgang, wie oben von mir paraphrasiert) finden sich im Archiv.
Dementsprechend fehlt es dann auch erwartungsgemäß an einer Begründung.
Die ist auch nicht unbedingt nötig. Niemand muss rechtfertigen, warum er einen bestimmten Beitrag subjektiv für passend oder für unpassend hält.
Was mich angeht (und von mir stammt eine der Negativbewertungen) bin ich aber gerne offen, trotzdem Auskunft über meine Beweggründe zu geben. Du lieferst sie im Prinzip schon selbst:
Beitrag von pl (der zugegebenermaßen an der Frage irgendwie vorbeigeht)
Ich empfinde den Beitrag subjektiv als nicht hilfreich, bezogen auf die Fragestellung des TO; immerhin bezieht sich die Frage ganz spezifisch auf PHP. Ich sehe im Posting auch kein Übertragungspotential auf PHP, da pl doch massiv unterschiedliche Konzepte anspricht, die in PHP in der Form nicht oder so unterschiedlich, dass eine eigene Anleitung vonnöten wäre, vorhanden sind.
Außerdem stimme ich mit der Aussage
Code mit HTML zu mischen ist keine gute Idee, da geht schnell die Übersicht flöten. So gab es auch in EmbPerl Versuche in diese Richtung, die sich jedoch nicht weiter verbreitet haben. Eine einfache Template-Engine die Skalare und Arrays rendern kann, reicht vollkommen. Bilde die Progammlogik NICHT im Template ab.
auch ganz generell nicht überein, wollte das aber nicht breittreten. Vor allem die scheinbare Allgemeingültigkeit dieser Aussage ohne wenn und aber stößt mir dabei auf.
Was definitiv nicht zutrifft, ist deine Vermutung
Hier spielen wohl eher persönliche Motive eine Rolle
Ich habe keinerlei Grund für irgendwelche persönlichen Animositäten (zudem ist pl aka Hotti schon deutlich länger dabei als ich und ich habe von ihm auch schon viele guten Beiträge gelesen); zudem wäre das auch nicht mein Stil, irgendwelche persönlichen Kleinkriege (die ich überhaupt gerne vermeide) auf diese Weise auszufechten[1].
Nicht zuletzt: Wenn der Beitrag tatsächlich, entgegen meiner persönlichen Einschätzung, von anderen als hilfreich wahrgenommen würde, würde er wahrscheinlich entweder positive Bewertungen erhalten oder sogar als Antwort vom TO akzeptiert werden - was meine Negativbewertung mehr als ausgleichen würde (im Faktor 10 bis 15 auf dem Punktekonto beziehungsweise durch prestigeträchtige Verlinkung des Postings). Es ist also nicht mal allzu dramatisch, wenn man mal zu Unrecht eine Negativbewertung erhält. Außerdem bemerke ich hier im Forum desöfteren einen Korpsgeist, in dem Sinne, dass Negativbewertungen nur dann ohne Konterbewertung stehen gelassen werden, wenn man die Gründe für die Negativbewertung intuitiv nachvollziehen kann - was die Gefahr einer gnadenlos unberechtigten Bewertung weiter senkt.
In der Hoffnung, dass nicht immer wieder und immer wieder solche Rechtfertigungen unnötigerweise verlangt oder gefordert werden,
Grüße,
RIDER
Was übrigens auch ziemlich witzlos wäre. Du darfst nicht vergessen, dass man für Negativbewertungen genau so viele Punkte verliert wie der negativ Bewertete - was würde mir das also bringen? Ich bezahle allerdings gerne immer mal wieder mit einem Punkt dafür, meiner subjektiven Meinung Ausdruck verleihen zu können, wenn mir ein Posting besonders (subjektiv) aufstößt. ↩︎
Moin!
In der Hoffnung, dass nicht immer wieder und immer wieder solche Rechtfertigungen unnötigerweise verlangt oder gefordert werden,
Ich denke schon, dass man das begründen sollte. Wenn man nämlich einen guten und sachlichen Grund hat, dann ist dem, dessen Antwort bewertet wurde, auch geholfen, denn er weiß nun, was in seiner Entäußerung aus welchen Beweggründen die Negativbewertung nach sich zog und er kann sich künftig daran orientieren.
Das weder juristische noch parajuristische noch quasijuristische "Verlangen oder Fordern" nach einer Begründung ist aus meiner Sicht einerseits eine Frage der gebotenen Wertschätzung und andererseits auch deshalb geboten, damit derjenige, dessen Beitrag öffentlich negativ bewertet wurde, (und sich also "stigmatisiert" fühlende) wegen der fehlenden Begründung (und zwar aus psychologischen Gründen geradezu zwangsweise) zu einer Auffassung über die Bewertung kommt, die der meinen zwar ähnelt, aber wegen der Selbstbetroffenheit (auch hier greifen psychologische Effekte) wohl etwas "heftiger" ausfällt. Der Betroffene kann sich sogar mit einiger Wahrscheinlichkeit "gemobbt" fühlen, was nicht der Fall ist, wenn ihm eine sachliche Begründung geboten wird. In einem Meinungsstreit könnten sich durch diese anonymen und scheinbar grundlosen Negativbewertungen Fronten verhärten und man kann jemanden hierdurch auch die Teilnahme am Forum vergrätzen.
Zum anderen sollte man wohl besser erst begründen und dann bewerten. Das schafft einem selbst Klarheit, ob die Negativbewertung sinnvoll, geboten oder (noch) notwendig erscheint. Vor allem ob es eine zweite sein muss...
Jörg Reinholz
Aloha ;)
In der Hoffnung, dass nicht immer wieder und immer wieder solche Rechtfertigungen unnötigerweise verlangt oder gefordert werden,
Ich denke schon, dass man das begründen sollte. Wenn man nämlich einen guten und sachlichen Grund hat, dann ist dem, dessen Antwort bewertet wurde, auch geholfen, denn er weiß nun, was in seiner Entäußerung aus welchen Beweggründen die Negativbewertung nach sich zog und er kann sich künftig daran orientieren.
Generell ja - ich verzichte aber dann auf eine ausschweifende Begründung, wenn das Fehl-am-Platz-sein sehr offensichtlich ist (meiner subjektiven Empfindung nach). Manchmal braucht es keine weitere Begründung, und im Zweifelsfall kann der negativ bewertete selbst noch einmal nachhaken, wenn er die Bewertungen unverständlich findet.
Insbesondere ist es manchmal genau nicht Sinn der Übung, die deplatzierte Thematik noch weiter breitzutreten (wie es bei einer Begründung, wie du siehst, sofort passiert). Das ist meistens, wie gesagt, wegen Offensichtlichkeit der Problematik auch gar nicht nötig.
Der Betroffene kann sich sogar mit einiger Wahrscheinlichkeit "gemobbt" fühlen, was nicht der Fall ist, wenn ihm eine sachliche Begründung geboten wird. In einem Meinungsstreit könnten sich durch diese anonymen und scheinbar grundlosen Negativbewertungen Fronten verhärten und man kann jemanden hierdurch auch die Teilnahme am Forum vergrätzen.
Da sind wir aber bei der grundsätzlichen Frage danach, ob es negative Bewertungsmöglichkeiten geben sollte - das ist eine Grundsatzfrage, die ich hier und jetzt ungern diskutieren möchte (weil in der Vergangenheit auch teils schon langatmig diskutiert wurde).
Zum anderen sollte man wohl besser erst begründen und dann bewerten. Das schafft einem selbst Klarheit, ob die Negativbewertung sinnvoll, geboten oder (noch) notwendig erscheint. Vor allem ob es eine zweite sein muss...
Die Frage, wie viele Personen sonst noch negativ bewertet haben spielt für mich zwar eine Rolle, aber doch eine untergeordnete. Übergeordnet stelle ich mir die Frage, ob ich für mich das Posting positiv oder negativ bewerte, und entscheide mich dann, falls meine Meinung nicht neutral ist, für den einen oder anderen Button. Ich bin allerdings auch insgesamt eher freigiebig mit Bewertungen (in beide Richtungen, vor allem mit positiven).
In einem Meinungsstreit könnten sich durch diese anonymen und scheinbar grundlosen Negativbewertungen Fronten verhärten und man kann jemanden hierdurch auch die Teilnahme am Forum vergrätzen.
In einem Meinungsstreit vielleicht - den sehe ich hier aber nicht gegeben. Das wären dann ja schon wieder fast persönliche Animositäten.
Ich denke auch nicht, dass man von einem negativ bewerteten Posting (unabhängig von der Anzahl der Negativvotings) zwangsläufig vergrätzt wird; das dürfte wohl eher der Fall sein, wenn negativ bewertete Postings an der Tagesordnung liegen. Und in diesem Fall sollte man sich wohl fragen, warum das der Fall ist, und ggf. sein Postingverhalten ändern, wenn einem die Bewertung an der Stelle wichtig ist.
Nicht zuletzt muss man sich aber auch einfach darauf einstellen, dass in einem öffentlichen Forum nicht immer alle jedermanns Meinung sind, und dass es dadurch schon mal dazu kommen kann, dass man Negativbewertungen einstecken muss - man darf allgemein an öffentlichen Stellen im Internet nicht zu dünnhäutig sein, sonst geht man mit falschen Erwartungen an die Sache heran.
TL;DR: Ich gebe dir prinzipiell Recht, sehe die Relevanz der ganzen Sache aber nicht derart hoch angesiedelt - und vor allem daraus keinen ableitbaren Grund, prinzipiell jede Bewertung aufgrund persönlicher Beweggründe gegenüber dem Posting-Inhalt zu begründen. Grüße,
RIDER
Moin!
ob es negative Bewertungsmöglichkeiten geben sollte - das ist eine Grundsatzfrage, die ich hier und jetzt ungern diskutieren möchte (weil in der Vergangenheit auch teils schon langatmig diskutiert wurde).
Ich hab mich da bewusst zurück gehalten und will diese Diskussion gewiss nicht verspätet anfangen. Das schon nicht, weil die selben Gründe, wegen denen ich mich zurück gehalten habe, immer noch gelten.
Was jetzt den konkreten Fall betrifft: PL hat früher so manchen interessanten Beitrag über Perl geliefert, nur fragt (hier) irgendwie derzeit "keine Sau" mehr danach. Jetzt mal ab in die Mokassins vom PL und dann überlegen ob man seinen Seitenhinweis à la "in Perl mache ich das so, nimm Dir davon was Du brauchst" nicht tolerieren kann. Einerseits wegen PL, andererseits weil PHP ja doch irgendwie einige Ideen von Perl aufgegriffen hat.
Und zumindest mit den (Ab)Sätzen
Code mit HTML zu mischen ist keine gute Idee, da geht schnell die Übersicht flöten. So gab es auch in EmbPerl Versuche in diese Richtung, die sich jedoch nicht weiter verbreitet haben. Eine einfache Template-Engine die Skalare und Arrays rendern kann, reicht vollkommen. Bilde die Progammlogik NICHT im Template ab.
Leider können die meisten mir bekannten Templateengines viel zu viel des Guten, bremsen am Ende alles aus und machen jegliche Performance-Optimierung zunichte.
hat PL ja durchaus interessante Ansätze zu einer - von der Programmiersprache unabhängigen - Diskussion über Teilaspekte des MVC-Geraffels (ich bin nicht so der Theoretiker) beigetragen.
Jörg Reinholz
Das ganze Gedöns von MVC, Design Patterns und OOP geht mir genauso glatt am Arsch vorbei wie euer Bewertungssystem. OOP mit Perl ist deswegen so schön, weil es 1. praktisch, 2. zweckmäßig und 3. nicht der OOP willens ist. Das heißt, es ist eben anders als mit anderen PLs.
Wer Klischee-OOP der OOP wegen programmieren will, bitteschön, der nehme halt PHP, Java oder setzt Moose auf Perl5 was deswegen immer noch Perl5 ist.
Ich habe mit Perl5 sehr erfolgreich programmiert, daran zu sehen, dass einst von mir und vor 10 Jahren entwickelte Programme heute immer noch produktiv wie wartungsfreundlich sind.
Was die Situation Perl betrifft, ist Perl5 mit Latein und Perl6 mit Esperanto vergleichbar. Auf de gesagt: Perl5 ist tot und Perl6 ist ein totgeborenes Kind. Ich für meinen Teil habe 15 Jahre gegen diese Situation angekämpft, mehr konnte ich nicht tun. Ich frage mich nur, was Andere von Perl6 erwarten, wenn sie das Potential von Perl5 gar nicht kennen.
Im Übrigen habe in in meinen letzten Berufsjahren auch Perlprogrammierer kennengelernt, die genauso bekloppt sind wie PHP-Programmierer: Dateienflut, Klassenflut und haufenweise Instanzen. Und dann hinterher fragen, wie Daten von einer Klasse in eine andere Klasse und womöglich noch nach MySQL zu transportieren sind. Oder wieder Andere, welche die ganze Geschäftslogik via Template::Toolkit direkt im HTMl-Template erledigen. Also eine Template-Engine als DAS Framework betrachten. Oder besser: Betrachteten, denn die lernen heute fleißig PHP. Viel Spaß weiterhin.
Aloha ;)
Das ganze Gedöns von MVC, Design Patterns und OOP geht mir genauso glatt am Arsch vorbei wie euer Bewertungssystem.
Gesunde Einstellung. Gut, dass sich @Jörg Reinholz umsonst Sorgen gemacht hat ;)
Grüße,
RIDER
Aloha ;)
Das ganze Gedöns von MVC, Design Patterns und OOP geht mir genauso glatt am Arsch vorbei wie euer Bewertungssystem.
Gesunde Einstellung.
Das beste Entwurfmuster ist Erfahrung. Interessiert leider keine Sau heute. Selbstverständlich dürfen Template und Code in einunderselben Datei notiert und dabei trotzdem sauber getrennt sein wenn ein kompakter Aufbau angestrebt wird (z.B. ein Loginformular als Kompaktklasse).
Und ja, warum nicht auch mal ein Template weiter unterteilen? Für verschiedene Ansichten kann das dann, aus Einer Datei geladen, beliebig zusammengesetzt werden (Tabelle, Formular, Textabschnitte). Bei Kontrollstrukturen innerhalb eines Templates liegt die Reihenfolge der Ausgabe fest. Bei Templatebausteinen nicht, da ist das variabel und das ist der Vorteil.
Und gerne nochmal: Geschäftslogik hat im Template nichts zu suchen. Code auch nicht. Hier um die Ecke hab ich das mal einem Geschäftsführer, der gleichzeitig Programmierer ist, vor 5 Jahren schon gesagt, dass er mit seinem EmbPerl nicht weit kommen wird wenn er mal was umbauen muss. Und was soll ich sagen: Genau dieser Fall ist nun massiv eingetreten. Meine Aussage, aus Erfahrung heraus getroffen, hat sich bewahrheitet. Aber solange Praktikanten für Umme verheizt werden können, wer braucht schon erfahrene Programmierer.pl
Hallo,
Ich beklage mich mal über den Missbrauch der Bewertungsfunktion. Hier spielen wohl eher persönliche Motive eine Rolle als die Vermutung, dass Beitrag von pl (der zugegebenermaßen an der Frage irgendwie vorbeigeht) grob unsinnig oder wirklich kritikwürdig wäre.
sicher ist er nicht "grob unsinnig", und auch nicht per se kritikwürdig.
Dementsprechend fehlt es dann auch erwartungsgemäß an einer Begründung.
Also wenn eine Frage im Raum steht, die ganz konkret auf PHP abzielt, und dann kommt einer und sagt, ich zeig dir mal, wie das in PHP geht, dann ist das IMO klar am Thema vorbei. Beim Aufsatz hätte man gesagt, Thema verfehlt, Fünf. Insofern haben die beiden abgegebenen Negativ-Votes meine innere Zustimmung.
So long,
Martin
Hallo Der Martin,
Also wenn eine Frage im Raum steht, die ganz konkret auf PHP abzielt, und dann kommt einer und sagt, ich zeig dir mal, wie das in PHP geht,
Perl ;-)
dann ist das IMO klar am Thema vorbei.
Jo.
Beim Aufsatz hätte man gesagt, Thema verfehlt, Fünf.
Sechs ;-)
Bis demnächst
Matthias
n'Abend,
Also wenn eine Frage im Raum steht, die ganz konkret auf PHP abzielt, und dann kommt einer und sagt, ich zeig dir mal, wie das in PHP geht,
Perl ;-)
klar, mein ich doch. :-)
Beim Aufsatz hätte man gesagt, Thema verfehlt, Fünf.
Sechs ;-)
Autsch. Bei uns konnte man damals auch für einen Aufsatz, der komplett am Thema vorbeiging, wenigstens noch eine Fünf bekommen, wenn's wenigstens sprachlich einigermaßen okay und in sich schlüssig war.
Ciao,
Martin
Hallo Der Martin,
Beim Aufsatz hätte man gesagt, Thema verfehlt, Fünf.
Sechs ;-)
Autsch. Bei uns konnte man damals auch für einen Aufsatz, der komplett am Thema vorbeiging, wenigstens noch eine Fünf bekommen, wenn's wenigstens sprachlich einigermaßen okay und in sich schlüssig war.
Ich weiß nicht, wie die aktuellen Regeln sind. Aber ich hatte einmal auch das Thema verfehlt und dafür eine Fünf bekommen und da das damals die schlechteste Note war, ...
Bis demnächst
Matthias
Hallo,
Fünf bekommen und da das damals die schlechteste Note war, ...
In der Oberstufe war ich immer froh über 5, manchmal gabs 2 oder sogar nur einen Punkt ;(
Gruß
Kalk
Tach!
- Wo ist es sinnvoll in einem komplexeren php-projekt welche php Dateien wo im MVC-Modell reinzupacken. .lib.php, .inc.php in model?
Ich setze einmal den @INC-Pfad und dann werden Methoden, die ggf. weitere Klassen inkludieren, automatisch geladen (Factory).
Die Frage ist sehr allgemein gehalten. Man kann sie nicht vernünftig beantworten, ohne einen großen Roman zu schreiben. Das was du da antwortest, ist nur ein kleiner Aspekt, wenn es um das Laden geht. Wo "die Dateien" (ohne dass ansatzweise Inhalte erwähnt wurden - Versäumnis des Fragestellers) jedoch einsortiert werden sollten, darauf geht deine Antwort mit keiner Silbe ein. Wenn @INC in Perl dasselbe wie include_path in PHP ist, dann gibt man damit nur ein oder mehrere Basisverzeichnisse an, mit denen relative Verweise auf Code-Dateien ergänzt werden, um so den eigentlichen Dateinamen zu bekommen.
Per externer Konfiguration kann ich URLs ein beliebiges Interface zuweisen, sei es um Platzhalter zu beleben oder die ganze Seite interaktiv zu machen.
Was soll eine externe Konfiguration sein? In welcher Art und Weise befindet sie sich nicht in der Anwendung selbst, sondern außerhalb? Und wie kommt die Anwendung an die Konfigurationsinformation heran?
Welche Bedeutung gibst du hier dem Wort Interface? Soll das ein Interface sein, das bei OOP eine Vereinbarung über beispielsweise Variablen und Funktionen bescheibt, und welches in Klassen implementiert werden kann? Oder ist das ein spezieller Ausdruck, den man in Perl verwendet? Gefragt war nach dem MVC-Muster. Da wird üblicherweise ein Request auf einen konkreten Controller geroutet. Ob das eine Klasse ist, die ein Interface (im OOP-Sinne) implementiert, spielt für das generelle Verständnis keine Rolle.
Und was hat der Anfang des Satzes mit dem Rest zu tun? Was genau wolltest du eigentlich zum Ausdruck bringen?
- Wie ist HTML in einer PHP-Datei aufgeteilt? Strikt getrennt oder wie beim Eingabefomular beide zusammen in einer Datei?
Sowohl als auch, das regelt die View-Class, da kann ich festlegen aus welcher Quelle das Template geladen wird und das kann auch unterhalb eines Token innerhalb derselben Datei liegen. In Perlmodulen ist für sowas unterhalb __ DATA __ ein idealer Platz für Templates.
Sowas ähnliches gibt es auch in PHP. Das ist aber völlig unüblich, weil man in PHP mit <?php und ?> beliebig oft "rein und raus kann". Man ist im Gegensatz zu Perl bereits von Anfang an im Template. Dass es trotzdem noch extra Template-Systeme gibt, hat andere Gründe. Jedenfalls hilft diese Antwort nicht viel, wenn man mit seiner Lösung konform zur PHP-Philosophie bleiben möchte.
Mit Hilfe einer geeigneten Boundary unterteile ich ggf. ein Template in mehrere Templates und kann mir das für die jeweilige Anwendung entsprechend zusammenbauen wobei dafür nicht extra weitere Dateien geladen werden müssen sondern nur Eine.
Auch das braucht man in PHP nicht. Wenn man sowas ähnliches in PHP machen wollte, würde man das Template vielleicht in eine Funktion setzen.
Matthias Apsel
Tabellenkalkfunction template_content() { ?>
<p>Template-Inhalt</p>
<?php }
function another_template_content() { ?>
<p>Noch ein Template-Inhalt</p>
<?php }
Ob das in der Form sinnvoll ist, oder es bessere Wege gibt, steht auf einem anderen Blatt.
Code mit HTML zu mischen ist keine gute Idee, da geht schnell die Übersicht flöten. So gab es auch in EmbPerl Versuche in diese Richtung, die sich jedoch nicht weiter verbreitet haben.
Welche Gründe gabs dafür? Liegt es vielleicht daran, dass Perl generell nicht (mehr) sehr häufig im Webumfeld zu finden ist und hauptsächlich für andere Einsatzgebiete verwendet wird?
Der erste Satz ist jedenfalls ein Allgemeinplatz, der stimmen kann, von dem aber auch das Gegenteil wahr sein kann. Übersicht kommt nicht automatisch zustande, wenn man ein System auseinandernimmt und dann vielleicht gar nicht weiß, wie die einzelnen Teile nun in welcher Situation zusammenspielen. Probleme mit der Übersicht liegen eher daran, dass ein Projekt aufgrund seiner Größe und Komplexität einen hohen Einarbeitungsaufwand erfordert. Natürlich gibt es auch Strukturen, die chaotisch gewachsen sind und deshalb schwer verständlich sind. Aber ich würde nicht behaupten, dass es per se übersichtlich ist, wenn Platzhalter im Template eingebaut werden und ihr Inhalt an anderer Stelle im Code ermittelt wird. Man könnte auch sagen, dass durch diese Trennung ein erhöhter Aufwand betrieben werden muss, damit beim Hinzufügen oder Entfernen von Platzhaltern im Template auch die andere Seite synchron gehalten wird. Am Ende bleibt es eine Entscheidung im konkreten Fall und Dogmen sind nicht die besten Ratgeber.
Eine einfache Template-Engine die Skalare und Arrays rendern kann, reicht vollkommen. Bilde die Progammlogik NICHT im Template ab.
View-Logik ist genauso Programmlogik wie Geschäftslogik. Du meinst mit Programmlogik vermutlich nur letzteres. Es spricht aber nichts generelles dagegen, View-Logik, wie das Verwenden einer Schleife zum Ausgeben von Daten aus einer iterierbaren Menge oder die Entscheidung, ob ein bestimmter Block oder ein anderer ausgegeben werden soll (if-else), in der View zu haben.
Natürlich kann man Templates auch völlig logikfrei gestalten. Das macht die Sache aber nicht generell besser, denn die Logik wird ja am Ende doch irgendwo gebraucht. Die Alternative ist, im Template nur Platzhalter zu haben und die Logik an anderer Stelle zu verwalten - auf dass man mindestens eine Stelle mehr hat, die man im Auge behalten muss.
Leider können die meisten mir bekannten Templateengines viel zu viel des Guten, bremsen am Ende alles aus und machen jegliche Performance-Optimierung zunichte.
Mehr Features, besonders solche, die man selbst gar nicht verwendet, machen eine Template-Engine oder ein System allgemein nicht zwangsläufig langsamer.
dedlfix.
P.s. zu Jörgs Missbrauchsverdacht. Ich wollte pls Antwort einfach nur unkommentiert stehen lassen und hab auch keine Bewertung vorgenommen. In der Vergangenheit habe ich mehrfach erlebt, dass Bemühungen den Aufwand nicht Wert waren und keinerlei Früchte zeigten. Ich will nicht sagen, dass ich die Wahrheit gepachtet hätte - ganz im Gegenteil. Nur habe ich den Eindruck, dass pls/hottis Antworten üblicherweise mehr Verwirrung stiften als aufklären. Begrifflichkeiten werden irgendwie verwendet, nur nicht so wie sie im Allgemeinen üblich sind. Auf konkrete Punkte angesprochen, kommt oft nur eine ausweichende Antwort, gern garniert mit einem "ist ja alles nicht so ernst gemeint"-Smiley ;) Ein fachlich beflügelnder Dialog kommt in der Regel nicht zustande. Ich kann es gut verstehen, dass sich aufgrund der wenig erkenntnisreichen Aussichten kaum einer mehr mehr Mühe machen möchte, als mit dem Minus zu signalisieren, dass da was nicht stimmen kann.
Tach!
- Wo ist es sinnvoll in einem komplexeren php-projekt welche php Dateien wo im MVC-Modell reinzupacken. .lib.php, .inc.php in model?
Ich setze einmal den @INC-Pfad und dann werden Methoden, die ggf. weitere Klassen inkludieren, automatisch geladen (Factory).
Die Frage ist sehr allgemein gehalten. Man kann sie nicht vernünftig beantworten, ohne einen großen Roman zu schreiben. Das was du da antwortest, ist nur ein kleiner Aspekt, wenn es um das Laden geht. Wo "die Dateien" (ohne dass ansatzweise Inhalte erwähnt wurden - Versäumnis des Fragestellers) jedoch einsortiert werden sollten, darauf geht deine Antwort mit keiner Silbe ein. Wenn @INC in Perl dasselbe wie include_path in PHP ist, dann gibt man damit nur ein oder mehrere Basisverzeichnisse an, mit denen relative Verweise auf Code-Dateien ergänzt werden, um so den eigentlichen Dateinamen zu bekommen.
Der Dateiname ergibt sich in Perl anhand des Modulnamen. Leider ist das in PHP u.a. PLs nicht so.
Per externer Konfiguration kann ich URLs ein beliebiges Interface zuweisen, sei es um Platzhalter zu beleben oder die ganze Seite interaktiv zu machen.
Was soll eine externe Konfiguration sein? In welcher Art und Weise befindet sie sich nicht in der Anwendung selbst, sondern außerhalb? Und wie kommt die Anwendung an die Konfigurationsinformation heran?
Konfiguriert wird für einen URL title, descr u.a. Attribute. So kann z.B. dem URL /index.html das interface=date zugewisen werden, was in /index.html einen Platzhalter fürs aktuelle Datum ermöglicht.
Welche Bedeutung gibst du hier dem Wort Interface? Soll das ein Interface sein, das bei OOP eine Vereinbarung über beispielsweise Variablen und Funktionen bescheibt, und welches in Klassen implementiert werden kann? Oder ist das ein spezieller Ausdruck, den man in Perl verwendet? Gefragt war nach dem MVC-Muster. Da wird üblicherweise ein Request auf einen konkreten Controller geroutet. Ob das eine Klasse ist, die ein Interface (im OOP-Sinne) implementiert, spielt für das generelle Verständnis keine Rolle.
Ein einfaches IF beschreibt mehrere Methoden, die bei JEDEM Request durchlaufen werden um die Response zu erzeugen. In Perl wie in PHP machbar.
Mit Hilfe einer geeigneten Boundary unterteile ich ggf. ein Template in mehrere Templates und kann mir das für die jeweilige Anwendung entsprechend zusammenbauen wobei dafür nicht extra weitere Dateien geladen werden müssen sondern nur Eine.
Auch das braucht man in PHP nicht. Wenn man sowas ähnliches in PHP machen wollte, würde man das Template vielleicht in eine Funktion setzen.
Das ergibt wieder eine unheilvolle Mischung von Template mit Code, hat sich nach meiner Erfahrung immer wieder als unzweckmäßig erwiesen. Daher empfehle ich auch, für MVC-Patterns PHP eben nicht als Template-Engine zu verwenden.
Welche Gründe gabs dafür? Liegt es vielleicht daran, dass Perl generell nicht (mehr) sehr häufig im Webumfeld zu finden ist und hauptsächlich für andere Einsatzgebiete verwendet wird?
In Perl hats lange Zeit an einer TE gefehlt, erst mit 5.8 ist HTML::Template in den Core gekommen. Eigenbau einer TE war in Perl Tagesordnung. Habe ich auch hinter mir und das war eine sehr gute Entscheidung.
Der erste Satz ist jedenfalls ein Allgemeinplatz, der stimmen kann, von dem aber auch das Gegenteil wahr sein kann. Übersicht kommt nicht automatisch zustande, wenn man ein System auseinandernimmt und dann vielleicht gar nicht weiß, wie die einzelnen Teile nun in welcher Situation zusammenspielen. Probleme mit der Übersicht liegen eher daran, dass ein Projekt aufgrund seiner Größe und Komplexität einen hohen Einarbeitungsaufwand erfordert. Natürlich gibt es auch Strukturen, die chaotisch gewachsen sind und deshalb schwer verständlich sind. Aber ich würde nicht behaupten, dass es per se übersichtlich ist, wenn Platzhalter im Template eingebaut werden und ihr Inhalt an anderer Stelle im Code ermittelt wird. Man könnte auch sagen, dass durch diese Trennung ein erhöhter Aufwand betrieben werden muss, damit beim Hinzufügen oder Entfernen von Platzhaltern im Template auch die andere Seite synchron gehalten wird. Am Ende bleibt es eine Entscheidung im konkreten Fall und Dogmen sind nicht die besten Ratgeber.
Template vom Code zu trennen hat sich immer wieder als zweckmäßig erwiesen. Gerade fürn MVC.
Natürlich kann man Templates auch völlig logikfrei gestalten. Das macht die Sache aber nicht generell besser, denn die Logik wird ja am Ende doch irgendwo gebraucht.
Nunja, if/else/endif sollte eine TE schon können.
Tach!
Der Dateiname ergibt sich in Perl anhand des Modulnamen. Leider ist das in PHP u.a. PLs nicht so.
Kann man aber in PHP so machen. Es gibt eine Autoload-Funktionalität, die man üblicherweise so implementiert, dass aus dem Klassennamen (gegebenenfalls auch Namespaces) der Dateiname gebildet wird.
Ein einfaches IF beschreibt mehrere Methoden, die bei JEDEM Request durchlaufen werden um die Response zu erzeugen. In Perl wie in PHP machbar.
Ich weiß nicht, ob es dazu einen Fachbegriff gibt, aber ein Interface ist das nicht. Das ist eher eine Ablaufsteuerung. Für einen bestimmten Request werden die Module X, Y und Z benötigt und es ist irgendwo definiert, dass diese drei Module abzuarbeiten sind.
Natürlich kann man Templates auch völlig logikfrei gestalten. Das macht die Sache aber nicht generell besser, denn die Logik wird ja am Ende doch irgendwo gebraucht.
Nunja, if/else/endif sollte eine TE schon können.
Ach, und warum sollte diese einfache Logik (innerhalb der View) dann nicht gleich als PHP-Code ausgeführt sein? Warum sollte dazu noch ein anderer Code verwendet werden, der erst noch in PHP übersetzt werden muss?
dedlfix.
Ich weiß nicht, ob es dazu einen Fachbegriff gibt, aber ein Interface ist das nicht. Das ist eher eine Ablaufsteuerung.
Jow. Wenn es immerwieder derselbe Ablauf ist, dann lohnt es sich, über ein Interface nachzudenken. So ist das IF schon der Core in meinem Framework; URL => Klassenbindung, Instanz wird erstellt. Meine IF-Methoden hier:
data()
ist für die Beschaffung des Templates zuständig. fehlt die Methode in der Subklasse, wird das Template unterhalb __DATA__ erwartet
init()
wie der Name schon sagt, initialisiert Attribute
browse()
wird nur aufgerufen, wenn der Request, KEINE Parameter mitbringt
control()
wird nur aufgerufen, wenn Parameter im Request sind
trailer()
kann ggf. auch noch bestimmte Platzhalter setzen
Meine IF Methoden werden aufgerufen, wenn sie in der Subklasse definiert sind. In Jeder IF Methode steht die Instanz der an URL gebundenen Subklasse zur Verfügung. Diese Instanz hält alles zusammen, von Request-Parametern bis zur Datenstruktur, in welcher die Platzhalter mit Werten betankt werden.
Allein schon über den logischen Wechsel browse()/control() lässt sich das View umschalten, indem bspw. ein anderes Template geladen wird.
Die Response schließlich wird gepuffert und nur dann inkl. aller mitgelieferten Header ausgeliefert, wenn es keine Fehler gab. Es können beliebige Content-Types ausgeliefert werden.
Ajax: Hier wird kein Template gerendert sondern nur die Datenstruktur für die Platzhalter serialisiert. Ob das XML, JSON oder binaries sein sollen, bestimmt der Request-Accept-Header.
Nunja, if/else/endif sollte eine TE schon können.
Ach, und warum sollte diese einfache Logik (innerhalb der View) dann nicht gleich als PHP-Code ausgeführt sein? Warum sollte dazu noch ein anderer Code verwendet werden, der erst noch in PHP übersetzt werden muss?
Kann. Im Beispiel hab ich Beides, ein Templatebaustein mit Platzhaltern und eine Bedingung:
--text_html_form-----------------------------------------------------------
%if_eavchdir%
<div>%content%</div>
%else%
<pre>%content%</pre>
%endif%
Kannst natürlich auch anders machen. Und machs nicht so kompliziert.pl
Aloha ;)
Ach, und warum sollte diese einfache Logik (innerhalb der View) dann nicht gleich als PHP-Code ausgeführt sein? Warum sollte dazu noch ein anderer Code verwendet werden, der erst noch in PHP übersetzt werden muss?
Kann. Im Beispiel hab ich Beides, ein Templatebaustein mit Platzhaltern und eine Bedingung:
--text_html_form----------------------------------------------------------- %if_eavchdir% <div>%content%</div> %else% <pre>%content%</pre> %endif%Kannst natürlich auch anders machen. Und machs nicht so kompliziert.pl
Letztere Aussage entbehrt nicht einer gewissen Ironie - immerhin hat dedlfix ja gerade den nicht-so-kompliziert-Weg propagiert (nämlich einfach direkt PHP-Code zu verwenden) und du favorisierst die kompliziertere Variante, die erst eine interpretierende Template Engine benötigt und im Templatefile keinerlei Vorteile gegenüber dem PHP-Code hat.
Grüße,
RIDER
Letztere Aussage entbehrt nicht einer gewissen Ironie - immerhin hat dedlfix ja gerade den nicht-so-kompliziert-Weg propagiert (nämlich einfach direkt PHP-Code zu verwenden) und du favorisierst die kompliziertere Variante, die erst eine interpretierende Template Engine benötigt und im Templatefile keinerlei Vorteile gegenüber dem PHP-Code hat.
Wahrscheinlich fehlt Dir einfach nur die Erfahrung, um den Vorteil einer Trennung Template/Code zu erkennen. Die kann ich nicht vermitteln, die musst Du selber machen.
Ich hab jedoch an einer anderen Stelle hier geschrieben, dass bei größeren Umbauten auch ein Praktikant den Vorteil einer solchen Trennung erkennen kann. Es macht am Ende alles einfacher.
PS: Meine Eigenbau Template-Engine hat 100 Zeilen Perl, nutzt RegExps und ist HTML::Template in Sachen Performance haushoch überlegen. Meine TE kann if/else/endif, loops und scalare und das ist schon alles was in der Praxis tatsächlich gebraucht wird.
Nochn Beispiel warum eine TE if/else/endif können sollte:
%if_eavchdir%
<fieldset><legend><strong>Neues Verzeichnis:</strong></legend>
<input name="dirname" style="width:20em">
<button name="mkdir" value="1">Anlegen!</button>
</fieldset>
%endif%
damit ein <form> zusammenbleibt und nicht in einzelne Templates zerstückelt werden muss. Der dazugehörige Platzhalter steckt in $self->{STASH}{eavchdir} wobei $self die Instanz der an den URL gebundnen Subklasse ist.
Aloha ;)
Letztere Aussage entbehrt nicht einer gewissen Ironie - immerhin hat dedlfix ja gerade den nicht-so-kompliziert-Weg propagiert (nämlich einfach direkt PHP-Code zu verwenden) und du favorisierst die kompliziertere Variante, die erst eine interpretierende Template Engine benötigt und im Templatefile keinerlei Vorteile gegenüber dem PHP-Code hat.
Wahrscheinlich fehlt Dir einfach nur die Erfahrung, um den Vorteil einer Trennung Template/Code zu erkennen. Die kann ich nicht vermitteln, die musst Du selber machen.
Ich gehe davon aus, dass ich über hinreichend Erfahrung mit PHP verfüge - aber mal abgesehen von diesem deinem Totschlagargument verstehe ich nicht, was deine Antwort mit dem zu tun hat, was ich geschrieben hatte. Das mag alles sein (oder auch nicht, teilweise), geht aber an meiner Aussage völlig vorbei.
Grüße,
RIDER
PS: Meine Eigenbau Template-Engine hat 100 Zeilen Perl, nutzt RegExps und ist HTML::Template in Sachen Performance haushoch überlegen.
Auch wenn es - mal wieder - komplett am Thema vorbei (you and me, tag team!) ist: Sicher?
PS: Meine Eigenbau Template-Engine hat 100 Zeilen Perl, nutzt RegExps und ist HTML::Template in Sachen Performance haushoch überlegen.
Auch wenn es - mal wieder - komplett am Thema vorbei (you and me, tag team!) ist: Sicher?
Lach. Und was heißt am Thema vorbei? MVC ohne Templateengine? Servus!
PS: Die Template-Engine als einen austauschbaren Layer einzubinden, ist natürlich auch eine Überlegung wert. Das heißt, welche TE angezogen werden soll, steht dann in der Konfiguration.
Hallo dedlfix,
Ein einfaches IF beschreibt mehrere Methoden, die bei JEDEM Request durchlaufen werden um die Response zu erzeugen. In Perl wie in PHP machbar.
Ich weiß nicht, ob es dazu einen Fachbegriff gibt, aber ein Interface ist das nicht. Das ist eher eine Ablaufsteuerung. Für einen bestimmten Request werden die Module X, Y und Z benötigt und es ist irgendwo definiert, dass diese drei Module abzuarbeiten sind.
Den gibt es, das nennt sich „Routing“ oder „Request Routing.“
LG,
CK
Tach!
Ein einfaches IF beschreibt mehrere Methoden, die bei JEDEM Request durchlaufen werden um die Response zu erzeugen. In Perl wie in PHP machbar.
Ich weiß nicht, ob es dazu einen Fachbegriff gibt, aber ein Interface ist das nicht. Das ist eher eine Ablaufsteuerung. Für einen bestimmten Request werden die Module X, Y und Z benötigt und es ist irgendwo definiert, dass diese drei Module abzuarbeiten sind.
Den gibt es, das nennt sich „Routing“ oder „Request Routing.“
Ah, Moment mal, Kommando zurück, ich hab mich verlesen. Ich las Module statt Methoden. Es geht also gar nicht um komplexe Ergebniserstellung aus mehreren Teilen, sondern nur um einfaches Finden desjenigen Programmteils, der die gewünschte Ausgabe in die Wege leitet. Die gängigen Begriffe dafür sind (natürlich) der Router, der aus den Request-Daten ermittelt, welcher Controller anzusteuern ist. Ob das eine Klasse ist, die ein Interface implementiert oder ob sie von einer Basisklasse erbt oder ob deren Methoden per Konvention benannt sind, sind Implementierungsdetails, die keine wirkliche Rolle spielen, wenn man das System generell beschreibt. Aber das schrieb ich ja schon in meiner ersten Antwort.
Es ist jedenfalls nicht hilfreich, einen konkreten Request auf ein abstraktes Gebilde, wie es ein Interface ist, routen zu wollen, beziehungsweise den Vorgang so zu beschreiben. Ein Interface beschreibt nur beispielsweise Methodensignaturen, hat aber keinen Code, der irgendwas tun könnte. Also kann man den Request nicht zu einem solchen routen, sondern eher zu einer Klasse. Wenn jemand verreisen möchte, und ich schicke ihn zu einem Bild eines Verkehrsmittels, reicht das nicht. Vielleicht meinte pl ja das richtige, aber gut gemeint ist nicht zwangsläufig verständlich beschrieben.
dedlfix.
Es ist jedenfalls nicht hilfreich, einen konkreten Request auf ein abstraktes Gebilde, wie es ein Interface ist, routen zu wollen, beziehungsweise den Vorgang so zu beschreiben. Ein Interface beschreibt nur beispielsweise Methodensignaturen, hat aber keinen Code, der irgendwas tun könnte. Also kann man den Request nicht zu einem solchen routen, sondern eher zu einer Klasse.
Richtig. URL => Klassenbindung. Schrieb ich doch.
Und: Die Subklasse implementiert ein Interface. Schrieb ich auch. Und das die Klassenbindung einer Konfiguration bedarf, sollte eigentlich auch klar sein oder ? Was daran verstehst Du nicht? Wenn Du serialisierte Hashes als Monolithen bezeichnest, dann darf ich meine Konfiguration auch Routing-Table nennen. Oder auch Projektverwaltung => maschinenlesbar und trotzdem kein XML ;)
Auf meiner Domäne /framework kannst Du das bis ins kleinste Detail nachlesen. Mein Perl-Framework, ja, das hatte ich auch mal in PHP gebaut. Ist aber in Perl alles einfachr zu machen, weil Perl eben nicht so pragmatisch ist. Ich hab mir von PHP auch einiges abgeguckt, kannste glauben. I.d.R. das, was man besser nicht machen sollte. Aber das Entity Attribute Value Model (EAV) zuerst bei Magento gelesen, hats mir wirklich angetan.
Bei mir gibts eine Methode: $self->eav('title','Neuer Titel für die Seite'); gibt mir den Vollzugriff auf alle Attribute welche fürn URL konfiguriert sind.
Per Konfiguration zugewiesene Interfaces definieren anonyme Methoden, in Perl sin das einfach nur Code-Referenzen. In Perl muss eine Klasse, die ein IF implementiert, nicht JEDE IF Methode definieren im Gegensatz zu PHP. Mein Trick in Perl: Vorschalten einer Funktion execute() die prüft per UNIVERSAL::can ob eine Methode definiert ist, wenn ja, liefert can() den Code der ausgeführt wird. so gibt es kein Problem mit redefined bei per Konfiguration zugewiesenen Interfaces.
In meinem FW werden IF-Methoden, bis auf eine Ausnahme nicht vererbt. Und im Unterschied zu PHP auch nicht implementiert. Perl ist eben doch ein bischen anders und am Ende wird vieles, ja sehr vieles um einiges einfacher als in PHP (hier müsste JEDE IF Methode definiert sein).
Ach: was mir Andere schon als MVC verkauft haben, Lach :)
Auf meiner Domäne /framework kannst Du das bis ins kleinste Detail nachlesen. Mein Perl-Framework, ja, das hatte ich auch mal in PHP gebaut. Ist aber in Perl alles einfachr zu machen, weil Perl eben nicht so pragmatisch ist. Ich hab mir von PHP auch einiges abgeguckt, kannste glauben. I.d.R. das, was man besser nicht machen sollte. Aber das Entity Attribute Value Model (EAV) zuerst bei Magento gelesen, hats mir wirklich angetan.
Die Idee, Objekte u.a. zyklische Strukturen auf genau 3 Datenfeldern abzubilden, hatte ich freilich sch'lange bevor ich mich mit Magento befassen musste. Einzig die Bezeichnung EAV hat mir gefallen, die Story ist hier: http://handwerkzeugs.de/dal.html
Und zum Interface: http://handwerkzeugs.de/hier.html