Referenz auf Teilstring?

Mit XML holst du dir einen riesen Wasserkopf in die Anwendung...

XML wird bevorzugt für den Austausch von Daten zwischen unterschiedlichen IT-Systemen eingesetzt, speziell über das Internet

aus Wikipedia

[sigurd]

Wie meinst du das genau?

[feuervogel]

@rambi: ich frage mich, wie du programmlogik von der präsentation trennen können willst, wenn du keine eigene zwischensprache in deinem templates hast. abgesehen davon, dass du gewisse größere projekte nicht mehr übersichtlich halten könntest ohne templates.

XML:
Tja... innerhalb einer Anwendung gibt es (meist) keine Notwendigkeit, eine XML Zwischen schicht einzuführen. Das Erzeugen und sofort wieder Parsen ist recht Resourcen fressend.

Templates:
Tja.. immer wieder eine Gradwanderung... Es gibt kein klares für und gegen bei der Frage. Auch hier gilt: Jede Art von Zwischesprache frisst Ressourcen. Ausserdem, wenn ich sage: "programmlogik von der präsentation trennen" dann meine ich nicht die Trennung zwischen PHP und HTML. Keine mir bekannte Templatesprache bringt irgendwas, zu dem PHP nicht in der Lage wäre...
Eins der heftigsten Beispiel dürfte Smarty sein:
Wunsch1: einfache Textersetzungen, dieses {variable} Gedöns
Wunsch2: wiederholungs Bereiche und Entscheidungen
Wunsch3: php in den Templates unterbringen
Und plötzlich hat man trotz einer (umfangreichen)Templatesprache wieder PHP Code in den Templates. Das ist schon fast pervers ;-)

Die Trennung von PHP und HTML ist mir erst wichtig, wenn Bausteine hinterher von Sitebetreiber noch geändert werden sollen. Es gilt, diese Entscheidung, was geändert werden darf schon in der Entwurfsphase festzulegen.

[feuervogel]

okay, einerseits heißt es nicht, dass wenn man templates benutzt, dass man im template php-code programmiert. dies wird sogar von den smarty-entwicklern ("ACHTUNG: Es wird dringend davon abgeraten, PHP-Code in Templates einzubetten") als schlecht bewertet.

zweitens: zwei freunde von mir arbeiten in einer recht großen software-entwicklungsfirma. dort ist ein mitarbeiter fest eingestellt, der den ganzen tag nichts anderes macht, als templates zu entwerfen. der kümmert sich nicht ums design oder grafiken, nein, er schreibt nur smarty-templates.

und jetzt erkläre mir, wie in so einer situation alles nur mit der von dir als "beste und schnellste" templatemaschine angepriesen wird, nämlich mit includes, gelöst werden soll? parallele (und damit meine ich wirklich zeitgleiche) bearbeitung und updates via svn? dann würde der laden pleite gehen.

und selbst in kleinen firmen wird meist arbeitsteilig gearbeitet.

desweiteren lässt sich grade mit smarty sehr schön caching implementieren, was grade wiederum resourcen spart! es geht hier ja nicht um hundertsel sekunden: wenn ich mir vorstelle, dass die startseite von einer seite mit 500.000 besuchern in der woche nicht gecached werden würde, dann hätte diese seite ganz schnell keine besucher mehr, und das caching bezieht sich nicht auf das php-code-caching sondern auf die gesamte ausgabe oder teile davon.

ich finde die template-sprache von smarty mittlerweile zu komplex und auch das generelle grundprinzip ein wenig überholt, da gibt es durchaus bessere alternativen.

Ich glaube nicht, dass wir hier und jetzt, einen Königsweg entwickeln können..

Und Ja! Arbeitsteilung ist in größeren Projekten nötig!

Der DB Designer kümmert sich um das Datenmodell
Der Anwendungs Programmierer bastelt die Controller und die Logikteile der View
Der Web Entwickler handelt die HTML und CSS Geschichten ab
Der Grafikdesigner macht die Bildchen und bestimmt Raumaufteilung Schriftgrößen usw..
Der Projektleiter hält den Affenstall in Spur!

Wichtig, an so einer Aufteilung ist, dass klare Schnittstellen geschaffen werden. Nur so ist die paralelle Entwicklung einzelner Teile möglich. Und ob der "Web Entwickler" jetzt <?=$this-blabli()?> schreibt oder {blabli} ist doch völlig wurscht! Dazu bedarf es nur rudimentäre PHP Kenntnisse.

[sigurd]

Hätte man nicht durch die dem MVC-Konzept zugrunde liegende Aufteilung insoweit einen Vorteil, als dass die Wiederverwendbarkeit des Codes so sehr hoch ist? Dadurch spart man Speicher (ok, wir bewegen uns im KByte und MByte-Bereich) und vor allem gewinnt man an Übersicht. Außerdem steigt so doch die Qualität des Programms bzw. des Codes oder? Und angesichts der leistungsfähigen Server heutzutage bewegen wir uns beim Generieren von PHP-Code doch trotzdem noch im ms-Bereich oder? Ich würde laienhaft behaupten, dass hier die Übersicht gegenüber der Generierungszeit im Vorteil ist.

Vielleicht könnte jemand zu meinen Behauptungen und Ansichten Stellung nehmen.

Hätte man nicht durch die dem MVC-Konzept zugrunde liegende Aufteilung insoweit einen Vorteil, als dass die Wiederverwendbarkeit von Code so sehr hoch ist? Dadurch spart man Speicher

Trugschluß!
wiederverwendbarkeit !== speichersparen

Außerdem steigt so doch die Qualität des Programms bzw. des Codes oder?

Nicht unbedingt, die Komplezität nimmt ehr zu.

dass hier die Übersicht gegenüber der Generierungszeit im Vorteil liegt.

Ganz mein Reden!!

[meikel (†)]

Zitat von sigurd

Und angesichts der leistungsfähigen Server heutzutage bewegen wir uns beim Generieren von PHP-Code doch trotzdem noch im ms-Bereich oder?

Ein schneller Server ist absolut kein Grund, lahmarschige Scripte zu basteln.
Außerdem wohnt das Script selten alleine auf dem Server und wird immer nur von einem User aufgerufen.

Eine Webapplikation ist kein Windowsmonster, bei dem die Sanduhr nen Drehwurm kriegt.

Ich würde laienhaft behaupten, dass hier die Übersicht gegenüber der Generierungszeit im Vorteil ist.

Der Wurm muß dem Fisch schmecken und nicht dem Angler!

Wenn Du irgend wann mal "Hochlast" Script schreibst, wirst Du Dich janz fix umstellen und Scripte schreiben, die schlichte HTML Seiten generieren und verlinken. Wie wir wissen, wird zu 99% gelesen und bestenfalls zu 1% geschrieben. <g>