-
@mermshaus
Von wollen kann gar keine Rede sein..
Ich weiß nicht wie es sonst gehen sollte?
ICh habe mir dein Link angeschaut und KURZ die Doku angeschaut. Ich dachte das ist die einzige Vorgehensweise.
Weitere Templates inkludieren hört sich ja nach dem Weg an den ich eigentlich suche.
Finde ich das schnell in der Doku? Stichwort 'include'?Einen Kommentar schreiben:
-
Du müsstest die Ausgabe zusätzlicher Templates entweder content1.phtml als Parameter zuweisen (etwa bei der render-Methode) oder die weiteren Templates in main.phtml oder content1.phtml inkludieren, wenn du an dem Inheritance-Ansatz festhalten willst.Zuletzt geändert von mermshaus; 30.03.2017, 15:15.Einen Kommentar schreiben:
-
@mermhaus
Vorlage 'Main-HTML' (main.phtml):
Dann habe ich einige content.phtml (content[n].phtml)-Templates.HTML-Code:<html> <head> <title>Mein Projekt</title> </head> <body> <div id="content1">{% block content1 %}{% endblock %}</div> </body> </html>
Diese content-datei (content1.phtml): wird u.a. so erstellt:
Wenn ich nun die main.phtml laden will mit der content1.phtml welche für den Block-Bereich 'content' ersetzt werden soll, dann muss ich ja folgendes machen:HTML-Code:{% extends "main.phtml" %} {% block content1 %} <div> <!--Hier halt der Inhalt der ich haben will wie z.B. für den Login-Bereich--> </div> {% endblock %}
Beachte: ich muss hier das einzufügende Template laden. Dieses ladet wahrscheinlich automatisch das main.phtml-Template weil dort das 'extends' auf diese main.phtml verweist (/votraussetzt ?).PHP-Code:$template = $twig->loadTemplate('content1.phtml');
So habe ich das ausprobiert und es funktioniert auch wunderbar.
ABER: was mache ich wenn ich weitere Templates in das Main-Template einfügen möchte? Natürlich in andere Block-Bereiche, nicht das wir uns da falsch verstehen...
Also hier nochmals mein main.phtml:
Und jetzt habe ich content1.phtml, content2.phtml, content3.phtml usw..HTML-Code:<html> <head> <title>Mein Projekt</title> </head> <body> <div id="content1">{% block content1 %}{% endblock %}</div> <div id="content2">{% block content2 %}{% endblock %}</div> <div id="content3">{% block content3 %}{% endblock %}</div> </body> </html>
Wie kann ich dann in PHP TWIG anweisen das main-Template mit allen Sub-Templates zu laden? Mit einem geht es wie ich es beschrieben habe, aber mehr als eins verstehe ich nicht?Einen Kommentar schreiben:
-
@Master0Blicker:
Der Frage zu Twig kann ich leider nicht wirklich folgen. Ein Codebeispiel würde vielleicht helfen.Einen Kommentar schreiben:
-
@SysOp:
Prinzipielle Zustimmung, dass OOP nicht immer die notwendigerweise „beste“ Option ist. Wobei ich da mit Qualifizierungen letztlich vorsichtig sein möchte, weil etwa ein Konzept nicht per se „schlecht“ oder „schlechter“ sein muss, nur weil es für einen Anwendungsfall vielleicht nicht optimal ist. Das (nicht auf dich bezogen) geht so in Richtung eines Pauschaldenkens, das meines Erachtens nichts bringt.Ich stelle immer wieder fest, dass aus OOP eine Art heilige Kuh gemacht wird, ist etwas in OOP programmiert, wird es per se als gut angesehen. Umgekehrt ist prozedualer Code immer böse. Ähnliches liest man bei der Verwendung von mail() und es gibt noch ein paar andere Punkte, denen man Verallgemeinerungen angedeihen lässt, die irgend wie zu Gesetzen erhoben wurden.
In Wirklichkeit hängt die Wahl des Stils auch von solchen Dingen ab, wie z.B. "wie viele Leute arbeiten an einem Projekt", oder "wie modular muss das ganze sein". Oft würde es reichen, wiederkehrende Aufgaben (z.B. deine Navigationsleiste) einfach in Funktionen auszulagern und der Code hätte alles, was er braucht auch ohne OOP.
Bei mail() kann ich aber aus Erfahrung sagen, dass man bei jedem Problem mit E-Mail-Versand sehr gut beraten ist, erst mal die bestehende Lösung durch eine aktuelle Mailerklasse zu ersetzen, bevor man weiter darüber nachdenkt.
Ich habe erst kürzlich was in der Richtung gemacht. Da landeten Mails mit „Postkartenbild“-Inhalten im Spam-Ordner. Der Versende-Code nutzte sogar eine (etwas dünne) Wrapper-Klasse um mail(), die auf mich ganz okay wirkte, aber 10 Jahre alt war. Da der Versand von Bildgrüßen ohne großartigen Text nicht gerade optimal ist, um *nicht* als Spam klassifiziert zu werden, hatte ich befürchtet, dass das nicht so einfach werden würde, die Geschichte zu retten. Ich habe es erst mal nur auf den PHPMailer umgestellt (was schon etwas Gebastel war, weil ich das Bild-Embedding (cid) für HTML-Mails umstricken musste) und gesagt, sie sollen es mal mit den Problemfällen testen. – Das hat tatsächlich schon gereicht. Das mit den Mailerklassen ist keine urban legend, die bloß jeder nachplappert.
Das dürfte auch damit zu tun haben, dass PHP letztlich doch sehr dicht an C dran ist. Viele PHP-Funktionen sind 1:1-Mappings zu C-Libs. Das ist kein Widerspruch zu deiner Aussage. Das ist aber glaube ich ein recht weitschweifiges Thema. Ich würde da wie gesagt einfach nicht versuchen, künstlich zu fundamentale Gegensätze zwischen den Paradigmen formulieren zu wollen. OOP ist auch nicht vom Himmel gefallen und hat bei Null gestartet und Programmierung neu erfunden. Das ist alles eher eine kontinuierliche Entwicklung, die immer auf dem aufgebaut hat, was schon da war. Dafür finden sich auch rasch Indizien, wenn man ein wenig darüber nachdenkt. Methoden in PHP heißen „function“, JavaScript hat kein syntaktisches „class“-Konstrukt, in Python ist – gefährliches Halbwissen – der erste Parameter einer Methode die Instanz (vergleiche etwa in PHP die mysqli-Funktionssammlung). C selbst kennt meines Wissens auch keine Klassen. Und letztlich müssen alle abstrakten Konzepte auch wieder in Bytecode und Assembler überführt werden, damit die CPU damit was anfangen kann.Anders gesagt:
Unterstelle ich den Entwicklern von PHP ein gewisses Mass an Voraussicht, könnte man sich auch fragen, wieso sie prozedualen Code überhaupt unterstützen und OOP nicht zwangsweise vorschreiben. Ich denke, dass sie die Notwendigkeit erkennen, dass jeder Stil durchaus seine Berechtigung hat und es manchmal einfach vernünftiger ist, etwas prozedual zu programmieren, als es immer in eine Klasse zu zwängen.
Letztlich ist das alles in gewisser Weise immer eine Suppe. Es sind alles nur syntaktische Abstraktionen, die es uns Menschen erleichtern sollen, Code zu schreiben, den wir besser nachvollziehen können (den wir überhaupt noch in endlicher Zeit verstehen können) und bei dem uns die Technik vor offensichtlichen Fehlern bewahren soll. Beispiel Sichtbarkeiten: Wenn was private ist, kann ich darauf nun mal nicht versehentlich zugreifen. Das kontrolliere aber nicht ich als Entwickler, das macht der Compiler für mich. Er nimmt mir Arbeit an, indem er auf Basis von Konventionen und bestimmten Regeln offensichtliche Fehler ausschließt. So habe ich als Entwickler mehr freie kognitive Kapazität, um die Komplexität der Gesamtanwendung besser verstehen zu können. Und je komplexer meine Anwendung ist, desto mehr brauche ich diese Hilfestellungen und desto mehr profitiere ich davon. Grob gesagt.
Das ist weder gut noch schlecht. Das ist einfach bloß eine Sache.
PS: Um den Blickwinkel noch zu erwähnen: Wenn ich fremden Code lese, ist es oft schwierig, den zu verstehen, weil Programmierung nun mal per se nicht so die simpelste Tätigkeit ist, die man ausüben kann. Deshalb bin ich für jede Sache dankbar, die mir das Verständnis erleichtert. Und Klassen mit Syntaxkonstrukten wie Sichtbarkeiten sind ein Vokabular, das dabei hilft, weil ein „private“ im Fremdcode die gleiche definierte Bedeutung hat wie in meinem eigenen Code. Je mehr Konventionen man befolgt, desto klarer und unmissverständlicher werden die Dinge – wenn alle Beteiligten die Konventionen kennen. Das ist bei syntaktischen Konventionen aber in der Regel der Fall. Bzw. setzt der Compiler (oder auch erst der Interpreter – je nach Sprache) ein gleichartiges Verständnis durch. – Wobei auch das im Umkehrschluss nicht ausschließen kann, dass es auch schlecht geschriebene Klassen gibt. Es reicht nicht, dass das „private“ da ist, es muss letztlich doch auch noch korrekt eingesetzt werden.Zuletzt geändert von mermshaus; 30.03.2017, 10:10.Einen Kommentar schreiben:
-
Rein prozedural schreib ich meist etwas, was nur einmalig läuft und nicht viel mehr als 50 Zeilen Code benötigt. Selbst bei solchen "Wegwerf-Scripten" kommt aber doch schnell der Punkt, ab dem es gewisse Vorteile mit sich bringt das in eine Klasse mit 2-3 Methoden zu packen auch wenn das dann lediglich Pseudo-Klassen sind die mit OOP nicht wirklich was zu tun haben. Es vereinfacht vieles und man behält in der Regel dadurch auch einen besseren Überblick.
Bei allem was darüber hinausgeht ist es in der Regel schon sinnvoll Objektorientiert zu arbeiten - dann sollte man sich jedoch zumindest mit den gängigsten Praktiken auseinandersetzen sonst kommt dabei nur irgendwelches Zeug raus, dass sich nicht wirklich gut nutzen lässt -> z.B. sowas https://de.wikipedia.org/wiki/GottobjektEinen Kommentar schreiben:
-
Da ist ein Raucher wohl anderer Ansicht.Zitat von SysOp Beitrag anzeigen
Wenn Ressourcen und Geschwindigkeit ein Thema werden, nimmt man in der Regel sowieso kein PHP.Zitat von SysOp Beitrag anzeigen
Und dass OOP langsam ist, stimmt vielleicht auch nur auf dem ersten Blick. Denn OOP betrifft ja nur den Programmcode. Was der Compiler daraus macht, ist wieder eine andere Sache. OOP-Code kann sogar schneller sein als prozeduraler Code.
Eine Automatikschaltung in einem Auto wird auch als langsam angesehen und eine manuelle Schaltung als schnell. Aber es gibt auch Automatikgetriebe, gegen die hat ein Handschalter nicht den Hauch einer Chance. Also was zählt ist nicht was davor ist, sondern was dahinter raus kommt.
Tja, aber spätestens dann, wenn man eine function bla() aufruft, die in OOP eine private function bla() wäre, da machts dann einen Unterschied.Zitat von SysOp Beitrag anzeigenEinen Kommentar schreiben:
-
OOP ist kein Muss, ist aber meistens zu bevorzugen. Das war mir schon klar im Großen und Ganzen.
Die Frage ist aber: wie weit treibt ihr das im Allgemeinen?
Bestehen eure Projekte 'nur' aus Klassen welche die Darstellung komplett generieren (ich gehe mal davon aus das dies aus DIV-Containern + Inhalt besteht) oder habt ihr zwischen den prozedualen Code-Schnipsel dann Objekte die z.B. Mails versenden, die DB-Verbindung managen und der Gleichen?
Erstellt ihr eine Klasse für den Body in HTML? Für jegliche DIV-Container eine Klasse usw.? Oder macht ihr 'einfach mal' und an Stellen, wo es Sinn macht, macht ihr dann eine Klasse?
Zu Twig nochmals:
Hat hier jemand damit Erfahrung? Wenn nein: gibt es ein Forum wo ich TWIG-User finde zum mit Fragen löchern? Ich würde gerne wissen wollen wie das mit dem 'inherit' auf viele Child-Elemente geht, wenn es überhaupt geht?Einen Kommentar schreiben:
-
Sorry, aber den Vergleich halte ich für misslungen, es spricht eigentlich nichts FÜR das Rauchen aber alles spricht dagegen!
Nüchtern betrachtet gibt es aber durchaus auch Argumente, die gegen OOP sprechen (z.B. Ressourcen-Bedarf, Geschwindigkeit).
Ich argumentiere hier auch nicht pro prozedzual und contra OOP (ich kann übrigens beides), stelle nur für mich persönlich fest, dass ich bisher auch sehr oft ohne ausgekommen bin ohne in meinen Augen nennenswerte Einbussen an Vorteilen verzeichnen zu müssen.
In vielen Fällen macht es auch kaum einen Unterschied, ob man nun public function bla () in einer Klasse anpasst oder eine function bla () in einer functions.php.Einen Kommentar schreiben:
-
Die Sache ist, wenn man einmal mal mit OOP angefangen hat, will man nicht mehr zurück.
Das ist ungefähr so wie Raucher, die jetzt Nichtraucher geworden sind. Die Nichtraucher wundern sich, warum die Raucher immer noch rauchen. Ohne Zigaretten ist das Leben doch so viel besser. Und die Raucher denken sich über die Nichtraucher: Lass mich doch in Ruhe, mein Opa hat auch geraucht und ist 90 Jahre alt geworden!Einen Kommentar schreiben:
-
@SysOp
Beruhigend zu wissen das man nicht auf Biegen und Brechen in OOP gezwängt werden muss.
Ich programmiere seit kurzer Zeit auch in Python. In einem sehr guten deutshen Forum bin ich intensiv unterwegs und habe schon einige male gehört -> ist nicht OOP, warum machst du das so und nicht 'richtig' (also OOP).
Um wieder in PHP ein wenig up-to-date zu sein, wollte ich eben wissen wie das hier so gesehen wird damit ich nicht im Start schon auf das falsche Pferd gesetzt habe.
Auch um dem vorzubeugen hier belächelt und belehrt zu werden wenn ich Codefragmente poste die klar nicht OOP sind wie in dem anderen Forum geschehen. Ist zwar nicht schlimm wenn das passiert, aber ich wäre schon gerne auf dem 'richtigen' Weg. Deiner Aussage und dem des anderen Users folgend gibt es viele richtige Wege und daher bin ich beruhigt.
DankeEinen Kommentar schreiben:
-
Ich weiß nicht ob ich hier fragen oder einen neuen Thread öffnen soll?#
Ich habe Fragen zu diesem Template-Ding namens 'Twig'.
Als ich den o.g. Link gefolgt bin und mir die Beschreibung dieser Template-Methode für das Trennen von PHP (Funktionalität) und HTML (Design) durchgelesen habe, war ich begeistert.
Nach der Installation von Twig (ist eigentlich nur in das Root-Verzeichnis ablegen), Implementierung in das Projekt und erstem (begiestertem) ausprobieren, ist mir aufgefallen das ich doch auf Probleme laufe.
Ich habe eine Root-HTML-Seite in der ich verschiedene Module (DIV-Container mit entsprechendem Content -> abhängig vom zu zeigenden Inhalt / Userinput) einbinde. Rein in PHP würde ich der 'Steuerungslogik' folgend, an entsprechenden Stellen die entsprechenden Objekte/Methoden ausführen.
In Twig (und wahrscheinlich in allen Template-Engines oder wie man diese auch nennt), kann ich Platzhalter im Root-Dokument (Parent) bestimmen, Dann ein Child-Element in Twig aufrufen mit HTML-Code für diesen Platzhalter und dort bestimmen welcher Parent Voraussetzung ist damit dieser dann automatisch geladen wird.
So, jetzt die Krux an der Geschichte:
Wie mache ich es wenn ich im Root-Dokument viele Platzhalter haben will und diese dynamisch einbinden möchte (der Steuerungslogik folgend)?
Das geht doch schon rein logisch gar nicht, oder habe ich da irgendwas falsch verstanden? Die TWIG-Doku ist ziemlich schwammig und es gibt diese nur in englisch. Ist für mich zwar normalerweise kein Problem, dennoch in Kombination mit schwammiger Beschreibung wird es schon schwer..
Daher meine Frage:
kenn sich hier jemand gut mit Twig aus und kann mir erklären ob ich ein Denkfehler diesbezüglich habe oder ob das damit gar nicht möglich ist zu realisieren daß man mit Templates + vielen Platzhaltern ein dynamisch veränderbares HTML-Dokument im LEGO-Bausteineprinzip umsetzen kann?
Oder habe ich da grundlegend eine falsche Vorstellung vom ganzen?
Wenn ich ein HTML durch PHP generiere, dann entscheide ich ja Bereich für Bereich was reingeschrieben wird, richtig?
Nehmen wir mal den Login->Bereich der oftmals oben rechts in der Head-Navibar untergebracht ist und links davon oftmals eine Navigation durch Themen der Seite betreffend.
Loginbereich / Div-Container:
Nicht Eingeloggt -> zeige im Login-Div das Loginformular an.
Eingeloggt -> zeige Username, Last-Login-Datum/Uhrzeit und den Logout-Knopf.
Navibar:
Ist nichts ausgewählt, gibt es kein 'Subnavigation' darunter. Div-Bereich für Subnavigation -> leer.
Ist im Haupt-Navigationsbereich ein Thema sugewählt, beinhaltet der darunterliegende subnavi-Bereich Unterthemen zum auswählen. Usw..
Alleine hier habe ich ja schon mehrere Platzhalter die dynamisch befüllt werden sollen. Dabei sind wir ja erst im Head-Title-Bereich...
Also kurz und bündig:
Kennt sich jemand mit Twig o.ä. aus? Und wie wird da ein dynamischer Seitenaufbau realisiert? Geht das überhaupt?
Ich hoffe auf eure Hilfe und bedanke mich schon einmal im Voraus!Einen Kommentar schreiben:
-
Super schöne Erklärung!
Ohne den Text kürzen zu wollen, es sind für mich 2 wesentliche Schlüsselsätze enthalten.
Ich stelle immer wieder fest, dass aus OOP eine Art heilige Kuh gemacht wird, ist etwas in OOP programmiert, wird es per se als gut angesehen. Umgekehrt ist prozedualer Code immer böse. Ähnliches liest man bei der Verwendung von mail() und es gibt noch ein paar andere Punkte, denen man Verallgemeinerungen angedeihen lässt, die irgend wie zu Gesetzen erhoben wurden.Es lässt sich aber auch mit Objekten in einem Stil programmieren, der ziemlich dem entspricht, was gemeinhin mit „prozedural“ gemeint ist.
....
Auch umgekehrt ist es sicherlich möglich, auch ohne Klassen Code zu schreiben, der von der Denkweise Richtung OOP geht
In Wirklichkeit hängt die Wahl des Stils auch von solchen Dingen ab, wie z.B. "wie viele Leute arbeiten an einem Projekt", oder "wie modular muss das ganze sein". Oft würde es reichen, wiederkehrende Aufgaben (z.B. deine Navigationsleiste) einfach in Funktionen auszulagern und der Code hätte alles, was er braucht auch ohne OOP.
Anders gesagt:
Unterstelle ich den Entwicklern von PHP ein gewisses Mass an Voraussicht, könnte man sich auch fragen, wieso sie prozedualen Code überhaupt unterstützen und OOP nicht zwangsweise vorschreiben. Ich denke, dass sie die Notwendigkeit erkennen, dass jeder Stil durchaus seine Berechtigung hat und es manchmal einfach vernünftiger ist, etwas prozedual zu programmieren, als es immer in eine Klasse zu zwängen.
Die Debatte OOP gegen "strukturierten Code" ist schon so alt, dass ich sie schon aus meine Anfangstagen kenne und das ist mittlerweile schon recht lange her.
Ich habe nie an wirklich grossen Projekten mit gearbeitet und bin in all den Jahren fast immer ohne OOP ausgekommen. Unstrukturiert würde ich meinen Code aber dennoch nicht nennen.
Aber was weiss ich schon, ich nutze ja auch mail()
Einen Kommentar schreiben:
-
@mermshaus
Wow, vielen Dank! Genau so etwas wollte ich wissen.
Und wenn noch mehr folgen sollte, dann nochmals danke schön und noch ein größeres Wow!
BTW:
Ich habe noch nie von diesen phtml-gehört oder gelesen. Ein View sagt mir auch gar nichts im Zusammenhang mit PHP.
Den Link werde ich mir heute Abend mal durchlesen und schauen ob das was für mich wäre.
Einen Kommentar schreiben:
Einen Kommentar schreiben: