Soweit ich das auf den ersten Blick sehe basiert das auf einen ganz anderen Konzept. Kannst du dafür bitte einen neuen Thread aufmachen. Fürchte dieser wird dann zu lang. Aber das ist nur meine Meinung.
Daher würde ich, wenn ich ein Template nur für mich selbst bräuchte, in der jeweiligen Sprache bleiben.
Die Einheit in der du Featurebedarf misst, ist nicht Anzahl Entwickler, sondern Komplexität der angestrebten Lösung. Wenn du nichts hinreichend Komplexes baust, dann brauchst du eben auch nichts Besonders für das Management der Darstellungsmasken.
Alles andere dient m.E. dazu jemand anderen, welcher nur in dieser Template-Sprache arbeitet, oder diese auch für andere Produkte nutzt, zu ermöglichen meine Software damit zu bedienen/konfigurieren.
Das kann auch ein Grund sein. Warum sollte ein Designer erst PHP lernen um mit dir zusammenarbeiten zu können? Ist aber nur ein Punkt von Vielen. "Layouting" ist auch noch so ein Feature, dass praktisch in jedem Projekt genutzt wird, dass ich kenne und was man nahezu unmöglich mit einfachem PHP umsetzen kann. Aber alleine der Umstand dass eine DSLmit einem zugeschnittenen Featureset idR wesentlich präziser ist, als PHP als Templatesprache, ist schon Grund genug.
Hätte ich eine entsprechende Anforderung, würde ich diese mit einer existierenden Template-Sprache bedienen, bzw. mich an dieser anlehnen und nicht unbedingt eine neue erfinden, auch wenn das manchmal einfach wirkt.
Eine Template-Engine wie Twig ist ja kein Selbstzweck, sondern eröffnet Möglichkeiten, die du nicht so ohne Weiteres nachbauen kannst. Und das sage ich insbesondere vor dem Hintergrund, dass es dich anscheinend schon belastest, wenn du deinen Kopf ein wenig aus der PHP-Blase strecken musst.
Ich habe selbst so einen Fall gehabt wo ich es anderen Admins über eine Weboberfläche ermöglichen wollte, Templates für die automatische Anlage von Jira-Tickets zu erstellen/ändern. Sie kombinieren dann in einer WebGUI Daten verschiedener Quellen mit diesen Vorlagen. Anfangs war das ein einfaches search/replace und ich verwendete eine simple "$VARIABLE" Schreibweise. Das hat eine Weile gut funktioniert. Dann aber kamen andere Anforderungen hinzu wie das festlegen eines Default-Wertes und die Möglichkeit an einer Position unterschiedliche Variablennamen verwenden zu können, welche sich je nach Quelle unterscheiden (z.B. sowas wie "firstname" und "givenname", welche dasselbe beinhalten) und schwubs war ich mittendrin in der Entwicklung einer eigenen Template-Sprache und musste meine bis dato kommunizierten Konzepte zigmal überarbeiten, dokumentieren und schulen. Daraus habe ich gelernt mir lieber gleich eine Template-Sprache wie Twig oder Jinja als Vorbild zu nehmen, selbst wenn ich am Anfang erstmal nur ein minimales Subset davon implementiere und das sogar mit einfachem str_replace() und keiner großen Engine. Aber ich kann direkt nach außen hin sagen "die Syntax findet ihr auf dieser Website/Standard-Beschreibung, bzw. such nach diesem Begriff". Und sollte ich dann dochmal mehr brauchen kann ich später immer noch meine Mini-Routine durch einen vollwertigen Engine-Parser ersetzen.
Kommentar