Wie generiert Ihr eure HTML Ausgaben?

Beim Erstellen von HTML Ausgaben gibt es ja mehrere verschiedene Möglichkeiten. Mit fallen derzeit drei ein, von daher stell ich diese auch mal in der Umfrage zur Auswahl mit einer kleinen Übersicht, was die drei im Details sind und was für Vor- und Nachteile ich persönlich darin sehe.
Bei reinen Java Servlets oder nicht eingebetteten Sprachen steht natürlich nur b) und c) zur Verfügung.
a) HTML Ausgaben als HTML Dokumente schreiben und die PHP/JSP Logik darin einbetten
Vorteile:

• Bei wenig Programmlogik hat man so einen guten Überblick über statische und dynamische Teile

Nachteile:

• Bei viel Programmlogik hat man sehr viele Mischungen zwischen HTML und der eingebetteten Sprache, was unübersichtlich werden kann

b) HTML Ausgaben nur mit PHP/JSP erzeugen im Sinne von "print('...');"
Vorteile:

• Wenn sämtliche oder große Teile dynamisch erzeugt werden, hat man einen besseren Überblick, da keine Mischungen benutzt werden

Nachteile:

• Es müssen mit unter ziemlich viele Ausgaben gemacht werden, wodurch die Korrektheit der Syntax darunter leiden kann

c) HTML Ausgaben mit Hilfe von HTML/XML Klassen erstellen im Sinne von "$body = $html->addNode('body');"
Vorteile:

• Dynamische Teile müssen Ihre Ausgaben nicht koordinieren, damit die Syntax stimmt (korrekte Verschachtelung der Tags), sie bekommen einfach ein Node Objekt, an welches sie ihre Ausgabe hängen.
• Die Syntax wird zentral erstellt und ist mit einer Korrekten Klasse auch immer richtig erstellt
• Das Entwerten von HTML Schadcode durch Benutzereingaben kann Zentral in den HTML/XML Klassen übernommen werden, was Cross Side Scripting und XSS eigentlich unmöglich macht
• Die Formatierung des HTML Dokumentes kann zentral definiert werden (und Einstellbar oder veränderbar über Parameter zum Beispiel auch über die URL). So ist es möglich die HTML Seite ohne jegliche Leerzeichen und Zeilenumbrüche zur Formatierung darzustellen (Perfekt für die laufende Version, da geringe Dateigröße und so schnellere Übertragung) oder per URL anschaltbar perfekt formatiert wie von einem Beautifuler (perfekt für Fehlersuche im HTML). (neu ^^)

Nachteile:

• Gewöhnungsbedürftig, da HTML nicht mehr als HTML geschrieben wird, sondern rein über Objekte und deren Methoden
• Kann mitunter etwas Performance kosten bei vielen Objekten und der Erstellung des fertigen Dokumentes

Ich persönlich würde bei mehrheitlich statischen Sachen a) nehmen und ansonsten immer c), da die Vorteile der korrekten Syntax und zentralen Entwertung von Schadcode die Nachteile erschlagen.
Was meint Ihr?
[COLOR=orangered][EDIT by Kampfhoernchen: Weitere Option hinzugefügt.][/COLOR]

d) Template-System, was ja wieder quasie ein wenig wie a) ist, also ganz stink normal

Ich wusste dass ich was vergessen habe ^^. Aber stimmt, Template System gehört ja zu a) eigentlich, ist ja misch masch (merkt man dass ich die nicht leiden kann? *gg*).
Ich versteh den Sinn dieser Systeme nicht, vor allem warum sollte ich eine Template Sprache lernen, wenn man mit ein paar PHP Befehlen genau das selbe Ergebnis bekommt. Kann man auch gleich PHP Benutzen im Template.

Naja könnte man so sehen, aber ich mach lieber kurz und knackig {if $a == $b}blabla>{else}bla{/if}, anstatt den käse mit "richtigem" php.
und die ganzen berechnungen, etc.. werden in den php dateien gemacht
Aber wenn ich nur was kleines programmiere, für freunde oder so, dann mische ich einfach html und php in einer .php file.

e) Eigenen Ordner mit PHP-Scripten welche für den Output verantwortlich sind. Damit sehr gute Trennung zwischen Applikations- und Publikationsebene.

Template-Systeme haben in der Regel gar nichts mit Lösung a zu tun und sind kein MischMasch.
Templates enthalten eigentlich nur Platzhalter und vielleicht nach Informationen zur Iteration. Aber man findet in Ihnen keine Programmlogik.
Das ist auch meine bevorzugte Lösung in PHP. Dabei setzte ich auch patTemplate.
In Rails nutze ich eher Ansatz a, allerdings mit einigen Einschränkungen. So gibt es bei mir keine Vermischung von View-Logik und Progammlogik. In den Views befindet sich nur Code für die Anzeige, alles andere ist im Controller. Hinzu kommt, dass ich soviel Anzeigelogik wie möglich in ViewHelper verpacke, womit der Ansatz recht nah an den Template Ansatz heran kommt.

d) Daten (in JSON) an den Client schicken und dort HTML erstellen.

Dass du mischen tust, heißt nicht, dass du die Logik mit in die HTML Ausgaben packst. Die können ja auch in eigene .php Dateien stecken, die keinerlei Ausgaben produzieren. Sodass im HTML Dokument mit PHP nur Variablen ausgibst oder auch eine Iterration baust bei Tabellen oder ähnlichem. Daher steckt in meinen Augen der selbe Sinn dahinter wie Template Systeme. Nur dass diese die Möglichkeiten sehr beschränken im HTML Dokument und so sicherstellen, dass View und Logik getrennt werden und ein Designer weniger Schrott machen kann als wenn er gleich alles in PHP machen darf.
@Nightflyer: Verzeichnisstruktur hat doch nichts mit der Ausgabe zu tun? Also würde ich aus dem e) nen b) machen weil deine .php Dateien rein die Ausgabe generieren, oder?

Original von DrakeL
Nur dass diese die Möglichkeiten sehr beschränken im HTML Dokument...

???
Mit Programmlogik war nicht die Geschäftslogik gemeint. Das sind zwei paar Schuhe. Ansonsten denke ich, ist es schon ein himmelweiter Unterschied, ob ich ein Template-System nutze, in dem Platzhalter gefüllt werden, oder ob man PHP-Anweisungen nutzt.
Gerade bei großen Projekten im kommerziellen Umfeld macht das einen Unterschied. Der Designer baut die die Seite auf und trägt einfach nur vorher abgesprochene Platzhalter ein, z.B. was in Richtung {TITEL}.
Die Datei kann somit einfach im Browser geöffnet und getestet werden, ohne das die PHP Anwendung im Hintergrund laufen muss. Der Designer muss sich nicht mit PHP und Wertformatierungen beschäftigen. Die Templates sind unabhängig von irgendwelchen Variablen und Bezeichnern im Code und damit völlig unabhängig. Und im Idealfall sind die Templates unabhängig von der eingesetzten Sprache.

Wenn schon c), dann kannst du auch platzsparend ein kleines(!) XML-Dokument bauen, und das dann mittels XSLT in ein schnieckes XHTML-Dokument umwandeln.
Ansonsten: a ist halt ein purer Quickie, wo man nachher kein Vergnügen mehr hat, b bietet mehr, kann aber auch unschön werden und c) ist toll, kann aber Zeit gebrauchen. Kann man doch so sagen? Für jeden halt etwas.

Jedes hat seine Vor- und Nachteile, deswegen gibt es auch kein perfektes System . Von daher klar kann man das so sagen. Ich würde keine statische Seite mit Templatesystem erstellen, nur um ein Counter zu haben. (so als krasses Beispiel ^^)
Templates haben für mich einen ganz krassen Nachteil, will ich ein Formular, muss ich auch das komplette HTML für das Formular jedes mal schreiben und kann da auch jedesmal wieder die selben Fehler machen. Und will ich sämtliche Formulare nicht mehr durch eine Tabelle sondern mit CSS in Form bringen muss ich auch alle Templates anpassen.
Bei b) änder ich einfach die Klasse die das HTML für das Formular ausgibt, bei c) die Klasse die mit Hilfe der HTML/XML Writer Klasse die Tags aneinanderknüpft.
Und gerade der Aspekt der Sicherheit, dass ich HTML und PHP Tags global an einer Stelle durch htmlentities entwerten kann ist in meinen Augen ein unschlagbarer Vorteil für HTML/XML Klassen.

Ich bastel immer noch allein und mag Smarty und co nicht.
Deshalb schreib ich die Ausgaben
und die Präsentationslogik direkt mit PHP ins Template.
Beispiel:
index.php

$array = ... ;
require 'index.tpl.php';
?>
index.tpl.php

Das ganze mag einem Entwickler der in einem Team arbeitet ein Dorn im Auge sein,
aber ich fahre ganz gut damit.
Und in Sachen Performance ist das nicht zu toppen ( mit PHP ).

Original von DrakeLTemplates haben für mich einen ganz krassen Nachteil, will ich ein Formular, muss ich auch das komplette HTML für das Formular jedes mal schreiben und kann da auch jedesmal wieder die selben Fehler machen. Und will ich sämtliche Formulare nicht mehr durch eine Tabelle sondern mit CSS in Form bringen muss ich auch alle Templates anpassen.

In Smarty zumindenst gibt es die Funktojn {include}
Und wenn du von Anfang an eine CSS Datei per HTML includest, musst du doch auch nur eine Datei anpassen (die Stylesheet Datei)?!
Oder verstehe ich da jetzt was falsch?

Bei CSS Sachen klar. Aber wenn ich den Aufbau eines Formulars im HTML ändern will. Dass es zum Beispiel keine Tabelle mehr ist mit einer Spalte für die Beschriftungen und eine Spalte für die Controls, sondern dass es ein Div Container ist mit links gefloateten Labels und den Controls.

Okay, verstehe, das ist dann wieder ne andere Sache...
obwohl du auch eine Datei namens "tabelle.tpl.html" erstellen könntest, mit dem tabellen-kram drinne. die könntest du includen und bei bedarf ändern
aber back to topic.

So ungefähr mach ich's, wenn ich z.B. das Inventar anzeigen möchte.

include( '...' );
?>
...
...
$page = new Inventory_Render( $db, $session, ... );
$page -> render();
$page -> output();
?>

Gruß,
Marc

Original von raufaser
So ungefähr mach ich's, wenn ich z.B. das Inventar anzeigen möchte.

include( '...' );
?>
...
...
$page = new Inventory_Render( $db, $session, ... );
$page -> render();
$page -> output();
?>

Gruß,
Marc

Das selbe sinngemäß mit einer HTML/XML Klasse:

$html = new HtmlDocument("Titel");

$page = new Inventory_Render( $db, $session, ... );
$page -> render();
$html->getBody($page);
Also da finde ich sogar Templates oder so besser als in jeder Datei das HTML Grundgerüst schreiben zu müssen.

Original von DrakeLAlso da finde ich sogar Templates oder so besser als in jeder Datei das HTML Grundgerüst schreiben zu müssen.

Also mein Dreamweaverchen macht das automatisch
Inklusive Doctype, etc pp

Original von DrakeL
Das selbe sinngemäß mit einer HTML/XML Klasse:

$html = new HtmlDocument("Titel");

$page = new Inventory_Render( $db, $session, ... );
$page -> render();
$html->getBody($page);
Also da finde ich sogar Templates oder so besser als in jeder Datei das HTML Grundgerüst schreiben zu müssen.

Ich persönlich sehe keine Notwendigkeit, mir eine Klasse in PHP zu schreiben, um das umgebende HTML für meinen PHP Code zu erzeugen. Ich hätte dadurch keinen Mehrwert.
Gruß,
Marc

• 4 Zeilen statt 18 bei jeder Seite.
• Bei jeder Seite keine Gefahr dass sich mal ein Fehler einschleicht.
• Globale Dinge wie JavaScript und CSS lässt sich unabhängig der Seite definieren (Ok, das geht auch mit einem Include, finde ich aber nicht so schön).
• Mehr Flexibilität, eine Stelle ändern um andere HTML Version zu benutzen (Das spricht in meinen Augen auch gegen die Lösung des Dreamweavers und Co. die können das zwar am Anfang reinschreiben, aber meist nicht global später ändern)

PS: Warum ist die Umfrage auf einmal mit 5 Punkten, wer ist der Schuldige? ^^ Ne Scherz, thx für denjenigen Mod oder Admin (denk ich) ders geändert hat. Ich finde das sollte auch der Threadersteller dürfen.

Diese HTML/XML Klassen sind ja sehr beliebt und es gibt eine Menge Bibliotheken dafür. Und waren die Dinger bei mir im Studium immer wieder eine beliebte Aufgabe der Professoren. Aber in der professionellen Entwicklung haben die eigentlich nicht zu suchen, da die Nachteile überwiegen:

• Sie sind nicht Sprachunabhängig. Die Designer müssen also die jeweilige Programmiersprache beherrschen
• Die ersten Entwürfe werden trotzdem in Plain HTML gemacht und müssen dann in die Klassen überführt werden, was doppelter Aufwand ist.
• Parallele Entwicklung wird erschwert. Ich kenne genug Projekte, wo die Entwicklung der Ansicht parallel zur Geschäftslogik betrieben wird und das ganze erst am Ende zusammen geführt wird.
• Man benötigt für jede Repräsentationsart eine eigene Klassenbibliothek. Bei einer Anwendung die z.B. RESTful entwickelt wird, würde dies in einer nicht wartbaren Menge von Klassen führen.
• Methoden müssen gegebenenfalls überladen werden, wenn kein globales Escaping gewünscht ist.
• Für jede dieser Klassen müssen Unit-Tests geschrieben werden. Eine Arbeit, die ich noch nciht mal einem Praktikanten zumuten würde.
• Das Debugging wird erschwert, da der HTML-Code auf zig Klassen und Methoden verteilt ist. Das ist noch schlimmer, als CompositeViews in JSP zu debuggen.

Da lobe ich mir doch meine drei Layout Dateien (ingame, outgame, admin), Templates und Partials. Alles sauber getrennt, modular, austauschbar, wartbar und RESTful.

Original von DrakeL

• 4 Zeilen statt 18 bei jeder Seite.
• Bei jeder Seite keine Gefahr dass sich mal ein Fehler einschleicht.
• Globale Dinge wie JavaScript und CSS lässt sich unabhängig der Seite definieren (Ok, das geht auch mit einem Include, finde ich aber nicht so schön).
• Mehr Flexibilität, eine Stelle ändern um andere HTML Version zu benutzen (Das spricht in meinen Augen auch gegen die Lösung des Dreamweavers und Co. die können das zwar am Anfang reinschreiben, aber meist nicht global später ändern)

1. Gehopst wie gesprungen (4 Zeilen in der Datei, dafür viel mehr Zeilen in der Klasse, die auch noch bei jedem Aufruf geparsed werden...)
2. Wenn Fehler, dann nur auf der einen Seite und nicht gleich in allen
3. script/style includes sind Bestandteil von HTML, daran ist nichts unsauber
4. Unflexibel, wenn du auf einzelnen Seiten speziellere Sachen machen willst
! IMHO !
Gruß,
Marc

(Listen sind dumm wenn man einzelne Dinge zitieren will ^^)
bei den meisten (vor allem den ersten ^^) Punkten muss ich dir Recht geben, da ich Einzelkämpfer im Projekt bin hab ich an Gewisse Dinge nicht gedacht.
Aber globales Escaping: Es gibt kein Grund es nicht zu wollen, außer du willst unsaubere Programmierung und die Möglichkeit HTML Teile als Value eines Nodes haben statt es als Child hinzuzufügen.
Unit Tests: Ich hab für 45 meiner Klassen Unit Tests, und die Tests, die für die HTML/XML Klassen sind, waren davon die einfachsten... Ich sehe kein Problem darin der Klasse ein paar Definitionen zu geben und dann abzugleichen ob die Ausgabe mit der gewollten übereinstimmt.
Das Debugging erschweren naja, wenn ich sehe dass in einer Navigationsliste etwas falsch ist schau ich mir die Klasse an für meine Navigationslisten, wenn in einem Formular was falsch ist die Formularklassen. Wenn man die Klassen schön sauber trennt, ist das doch kein Problem. Da wär ich für jeden Bug darin dankbar, wenn dafür ein Bug in einer Klasse wie dem Kampfscript entfällt. Ich sehe aber hier nen großer Vorteil, geht ein Formular richtig gehen alle Formulare. Änder ich den HTML Code auf Grund eines Fehlers in der Formularklasse, ist die Änderung in allen Formularen enthalten. Finde ich ein Fehler in einem Template weil jemand nicht genau wusste wie man ein Formular erstellt, muss ich alle Templates durchsuchen.

Original von DrakeL
bei den meisten (vor allem den ersten ^^) Punkten muss ich dir Recht geben, da ich Einzelkämpfer im Projekt bin hab ich an Gewisse Dinge nicht gedacht.

Das war mir schon klar. Aber man muss bei so etwas halt immer aufpassen, ob es das richtige für einen bestimmten Einsatzzweck ist, oder allgemeingütig ist. Und nicht um sonst, gehören die Prinzipien, die hinter TemplateEngines stecken zu den gängigen Entwurfsmustern. CompositViews seien da nur als Beispiel genannt.

Original von DrakeL

Aber globales Escaping: Es gibt kein Grund es nicht zu wollen, außer du willst unsaubere Programmierung und die Möglichkeit HTML Teile als Value eines Nodes haben statt es als Child hinzuzufügen.
Auf globales Escaping zu verzichten hat nichts mit unsauberer Programmierung zu tun. Es gibt genug Anwendungsfälle, in denen Escaping nicht gewünscht ist. Denk nur mal an CMS Systeme oder Anwendungen, die Whitlists verwenden, um z.B. Rich Text Editoren zu verwenden.

Original von DrakeL

Unit Tests: Ich hab für 45 meiner Klassen Unit Tests, und die Tests, die für die HTML/XML Klassen sind, waren davon die einfachsten... Ich sehe kein Problem darin der Klasse ein paar Definitionen zu geben und dann abzugleichen ob die Ausgabe mit der gewollten übereinstimmt.
Auch hier vermute ich, dass Du den Aufwand aufgrund der Projektgröße und Komplexität unterschätzt. Um solche Klassen vollständig zu Testen, und ich denke da an eine R3 Testabdeckung müssen ziemliche viele Test-Fixtures hinterlegt werden, die jeweils eine ganze Menge HTML-Code enthalten. Das führt sehr schnell zu Problemen, weshalb man ja auch versucht, relativ atomare Werte zu testen und View Tests auf andere entsprechende Technologien zu verlagern. Kann man hier zwar auch machen, was aber mit den Programmierrichtlinien des Projekt kollidieren kann.

Original von DrakeL

Das Debugging erschweren naja, wenn ich sehe dass in einer Navigationsliste etwas falsch ist schau ich mir die Klasse an für meine Navigationslisten, wenn in einem Formular was falsch ist die Formularklassen. Wenn man die Klassen schön sauber trennt, ist das doch kein Problem. Da wär ich für jeden Bug darin dankbar, wenn dafür ein Bug in einer Klasse wie dem Kampfscript entfällt. Ich sehe aber hier nen großer Vorteil, geht ein Formular richtig gehen alle Formulare. Änder ich den HTML Code auf Grund eines Fehlers in der Formularklasse, ist die Änderung in allen Formularen enthalten. Finde ich ein Fehler in einem Template weil jemand nicht genau wusste wie man ein Formular erstellt, muss ich alle Templates durchsuchen.
Auch hierfür gibt es wieder entsprechende Entwurfsmuster (ViewHelper). Hier z.B. ein Auszug aus meinem RESTful Interface für das Bearbeiten von Einheiten:

Einheit bearbeiten

<%= error_messages_for 'unit' %>
<% form_for :unit, @unit, :url => unit_path(@unit), :html => { :method => :put } do %>
<%= render :partial => 'form' %>
<%= submit_tag 'Änderungen speichern' %>
<% end %>
Da nutze ich zwar keine echte Template-Engine, aber es ließe sich 1:1 darauf übertragen.

Original von Agmemon
Auf globales Escaping zu verzichten hat nichts mit unsauberer Programmierung zu tun. Es gibt genug Anwendungsfälle, in denen Escaping nicht gewünscht ist. Denk nur mal an CMS Systeme oder Anwendungen, die Whitlists verwenden, um z.B. Rich Text Editoren zu verwenden.

$html = new HtmlDocument();
$html->disableEscaping();
$html->getBody()->setValue('Jetzt darf ich coole Links setzen ');
(Mir in Bugtracker eintrage, gute Idee ne Einstellungsmöglichkeit einzubauen, lässt sich sogar ohne Probleme auf einzelne Nodes beschränken oder rekursiv auf alle darunter liegenden mit dazu).

Original von Agmemon

Auch hier vermute ich, dass Du den Aufwand aufgrund der Projektgröße und Komplexität unterschätzt. Um solche Klassen vollständig zu Testen, und ich denke da an eine R3 Testabdeckung müssen ziemliche viele Test-Fixtures hinterlegt werden, die jeweils eine ganze Menge HTML-Code enthalten. Das führt sehr schnell zu Problemen, weshalb man ja auch versucht, relativ atomare Werte zu testen und View Tests auf andere entsprechende Technologien zu verlagern. Kann man hier zwar auch machen, was aber mit den Programmierrichtlinien des Projekt kollidieren kann.
Ich decke bisher nur die groben Testfälle ab. Das reicht für mich vollkommen und von daher sind meine Funktionen für einzelne Unit Tests nicht größer als 10 - 30 Zeilen (ohne Kommentare versteht sich ^^).

Original von Agmemon

Auch hierfür gibt es wieder entsprechende Entwurfsmuster (ViewHelper). Hier z.B. ein Auszug aus meinem RESTful Interface für das Bearbeiten von Einheiten:

Einheit bearbeiten

<%= error_messages_for 'unit' %>
<% form_for :unit, @unit, :url => unit_path(@unit), :html => { :method => :put } do %>
<%= render :partial => 'form' %>
<%= submit_tag 'Änderungen speichern' %>
<% end %>
Da nutze ich zwar keine echte Template-Engine, aber es ließe sich 1:1 darauf übertragen.
In wie weit eine Template Sprache einfacher und verbreiter ist wie PHP/JSP lässt sich streiten. Fakt ist mit PHP/JSP erreiche ich das selbe ohne merklichem Mehraufwand und ohne zusätzlichen Performanceverlust für das Parsen.
PS Hab noch ein Vorteil gefunden für HTML Klassen, werde ich im Startbeitrag gleich hinzufügen.

Also ich nutze anscheinend viele der angegebenen Möglichkeiten.
Beispiel (gerade aus den Fingern gesaugt):
So sieht ungefähr jede Haupt-Datei aus:

include('header.php');

$Template->set('title', 'Nachrichten');
$content = $User->messages();
$Template->set('content', $content);
$Template->display();

class User{

public function messages(){
$sql = 'SELECT * FROM messages WHERE userid="'.$this.>id.'"';
$arr = $mysqli...
return Messages::table($arr);
}
}

class Messages{

public static function table($arr){
$table = '';
foreach($arr AS $key => $value){
$table .= ''.$value.'';
}
$table .= '';
return $table;
}
}

class Template{

public function set($key, $value){
$this->smarty->assign($key, $value);
}
public function display(){
$this->smarty->display($this->tplfile);
}
}

{$title}
{$content}

Das ist jetzt natürlich nur grob, die Klasse Template z.B. macht noch vieles mehr, sonst würde sie sich ja nicht lohnen

Was hindert dich hier daran deine Template Funktionalitäten Konsequent zu nutzen, daher auch ein Template für deine Messages zu machen und dieses dann auch zu verwenden?

Ich weiß es nicht genau...
Es ist wohl eine Mischung aus Faulheit, Bequemlichkeit und Quick-and-Dirty

Templatesysteme haben zwar Ihre Schwächen (genau wie alle anderen Dinge auch), aber ich finde es schlimmer es einmal so zu machen und einmal so, statt konsequent Templates zu benutzen.

DrakeL, du musst nicht Jeden versuchen "zu bekehren"... dann hätte eine Vote Option nämlich gereicht...
Gruß,
Marc

Hey, wieso bekehren, ich hab gerade gesagt er soll seine Templates wenigstens konsequent einsetzen. ^^
Ich sehe schon ein dass die Ihre Vorteile haben, nur überwiegen für mich mit meinen Bedürfnissen die Vorteile der HTML/XML Klassen. Deswegen benutz ich Sie. Aber das muss jeder für sich entscheiden, welche Vorteile er haben will und ob er dann auch mit den Nachteilen davon Leben kann.
Nur wenn halt einer was gegen das System sagt, das ich nutze, dann will ichs ja auch verteidigen. ^^ Zumindest hab ich immer den Drang dazu.

Original von DrakeL
Nur wenn halt einer was gegen das System sagt, das ich nutze, dann will ichs ja auch verteidigen. ^^ Zumindest hab ich immer den Drang dazu.

Das merkt man...
Auch an den 240 Beiträgen in der kurzen Zeit.
Und man lasst doch mal das scheiss ^^^^^^^^^^^^^^^^^^
Hier und da mal ein Emoticon um etwas auszudrücken,
aber nicht nach jedem Satz.

Das ist doch noch moderat - ^^
Agmemon, das läßt mich an meinen kleinen RoR-Workshop erinnern, wenn ja: Das ist doch sehr stark an MVC ausgelegt (könnte man durchaus behaupten ) - wo wir also wieder bei "Sprachabhängigkeit" wären. Ich kann mir nicht so gut vorstellen, dass dies beispielsweise in PHP so effizient lösen ließe :/ Also, so Richtung b/c.. oder wie das jetzt im neuen Voting ist (überfragt)?

Original von Amun Ra
Das merkt man...
Auch an den 240 Beiträgen in der kurzen Zeit.

Anwendungsentwickler ist mein Hobby und mein Traumberuf, den ich auch habe. Sorry wenn ich mich für dieses Thema sehr interessiere und mich daher gerne aktiv an Diskussionen beteilige. Ich versuch halt in solchen Diskussionen festzustellen, was die Vor- und Nachteile der verschiedenen Systeme sind um vielleicht eine bessere Lösung für meine Vorgehensweise zu finden.
Immerhin hab ich durch die Diskussion mit Agmemon gemerkt, was die Vor- und Nachteile meiner Vorgehensweise und der Templatesysteme sind und habe mehrere Änderungen an meinen bestehenden Klassen vorgenommen (zum Beispiel die Möglichkeiten das Escaping abzuschalten) und kenne nun auch die Anwenungsgebiete in denen Templatesysteme meiner Vorgehensweise deutlich überlegen sind.

Original von Amun Ra

Und man lasst doch mal das scheiss ^^^^^^^^^^^^^^^^^^
Hier und da mal ein Emoticon um etwas auszudrücken,
aber nicht nach jedem Satz.
Wenn meine Lebhafte Schreibweise unerwünscht ist, werde ich versuchen mit hier etwas ernster der Sache zu widmen.

Original von DrakeL
Wenn meine Lebhafte Schreibweise unerwünscht ist, werde ich versuchen mit hier etwas ernster der Sache zu widmen.

Du hast eine gute und verständliche Schreibweise, dir das dauernde "^^" abzugewöhnen, wäre aber noch ein echter Gewinn.
Und Smileys sind doch so oder so viel schöner. :-)
back2topic:
Natürlich hat jedes System Vor- und Nachteile. Ich glaube das ist wirklich immer eine sehr individuelle Entscheidung, die nicht nur vom Projekt, sondern auch von der Persönlichkeit des Programmierers abhängt. Der Eine denkt eben so, der Andere so...
Gruß,
Marc

( DrakeL ich find deine Aktivität echt lobenswert, weiter so... aber raufaser hat recht )

Original von knalli
Agmemon, das läßt mich an meinen kleinen RoR-Workshop erinnern

Ja, das Beispiel stammt aus meinem Rails BG. Wollte damit DrakeL nur zeigen, dass es auch basierend auf den anderen Lösungen die Möglichkeit gibt, HTML-Elemente zu kapseln. In der Form liesse es sich auch mit reinem PHP umsetzten, oder aber auch durch Subtemplates, je nach Engine.
Alternativ könnte man sich aber auch noch CakePHP angucken, wo die MVC Trennung schon implementiert ist.

Meine Methode steht hier auch nciht zur Auswahl. Ich habe ein einzelnes in C programmiertes Programm, das sowohl Serverprogramm als auch Datenbank, HtML Generator sowie Berechnungsprogramm ist. Und Evergore macht soviel ich weiss etwas ähnliches.
Ich hab mal Template System angekreuzt, da dies noch am ehesten hinkommt.

@Sogil das versuche ich auch gerade,
muss aber feststellen das C nicht so ne Bubisprache wie PHP ist

C oder C++?
Ich wüsste keinen Grund ein solches Programm in C++ schreiben zu sollen. Dann doch lieber Java. Kommt in der Performance immer näher und ist weniger Fehleranfällig als Zeiger oder überladenen Operatoren.

In C.
An die Performance von C kommt halt nichts ran.
Außer vielleicht C++, D oder Clean.
Aber Java sicher nicht.
Wollte das nur zum lernen mal testen,
mal über den Tellerrand schauen.

Ob Java langsamer oder schneller als C/C++ ist kommt doch stark auf das verwendete Framework an.
Wir benutzen fast ausschliesslich C++ und das funktioniert wunderbar.
Das sieht dann z.B. so aus:

Stream& xsOut=p_pxReq->Out();
xsOut.PrintF("PlayerName;Score;Faction;Ally\r\n");
int i,iC=axE.GetSize();
for(i=0;i
{
AStr sName,sAlly;
int iFaction;
m_pxMgr->GetSimplePlayerInfo(axE.m_iPlayerID,sName,iFaction,sAlly);
xsOut.PrintF("%S;%I64d;%d;%S\r\n",sName.c_str(),axE.m_iScore,iFaction,sAlly.c_str());
};
%S ist hier übrigens die JSON-safe Variante von %s

Wenn man denkt im Webbereich High End Performance zu gebrauchen und dafür Sachen wie OOP und sonstige schöne Dinge verzichten zu können, ist man bei C genau richtig.
Dann hat man wohl irgendwann ein Spiel, das verdammt schnell ist, aber nicht mehr wirklich wartbar oder erweiterbar. Man sollte auf die Performance achten, aber man sollte wissen, wo die Grenzen sind.
Jeder das was er will. Früher ging es ja auch ohne diese Spielereien.

Ohne den kompletten Thread zu lesen geb ich mal meinen Senf dazu:
Ich nutze auch ein Templatesystem aber keins alá Smarties welches ne komplett neue Templatesprache erfindet. Denn ne Templatesprache in ner Templatesprache ist etwas sinnlos.
Mein System ist dem von Amun Ra ähnlich.
Nur die Ausgabe einer Variable sieht bei mir anderes aus.

Der Nachteil dabei ist bloss, dass eine Gewisse Einstellung (Name der Einstellung müsste ich jetzt nachgucken), welche die
Auch binde ich meine Templates anderes ein - dafür sorgt eine Klasse mit 27 Zeilen.
Wenn es interessiert (Klasse gibt es ähnlich im Internet ich habe sie nur verbessert):

class Template
{
private $file = '';
private $vars = array();

public function __construct( $file = null ) {
$this->file = $file;
}

public function set( $key, $value ) {
$this->vars[$key] = ( $value instanceof Template ) ? $value->fetch() : $value;
}

public function fetch( $file = null ) {
if( !$file )
$file = $this->file;

extract( $this->vars );

ob_start();
require( $file );
$contents = ob_get_contents();
ob_end_clean();

return $contents;
}
}

Wieso denn nur nicht wartbar oder erweiterbar ?
Das stimmt doch so nicht...
Na egal, wir kommen da nicht auf einen Nenner.
@CO auf den Schnipsel schau ich noch wie ein Schwein ins Uhrwerk
Edit:
@n26 short tags sind bäh Geschmackssache...

Der Schnipsel soll eigentlich nur demonstrieren, dass C++ nicht automatisch heisst, dass es umständlich zu coden ist.
Beispiel:

Stream& xsOut=p_pxReq->Out();
xsOut.PrintF("PlayerName;Score;Faction;Ally\r\n");
p_pxReq ist ein Pointer auf den Request. xsOut ist unser HTTP-Outputstream.
Mit der Kapselung haben wir den netten Effekt, dass die Ausgabe (wahlweise) gleich beim Erzeugen gezippt wird. Ausserdem ist der dahinterliegende Speicher gleich so angelegt, dass er direkt dem Kernel für's Senden übergeben werden kann (ohne weitere Kopien).
Also zusammen: Bequem und performant.

Original von Amun Ra
@n26 short tags sind bäh Geschmackssache...

Ich würde ja fast nich geht nutze ich shorttags aber dadruch dann auch vor zb foreach, if etc. ...

Die Betonung (bei mir zumindest) lag auf die Tatsache, dass kein C++, sondern wirklich C verwendet wird. Für mich unverständlich, warum man auf Bequemlichkeit und Wartbarkeit komplett verzichtet und Jahrzehnte zurück geht in der Entwicklung.
C++ kann auch bequem sein keine Frage. Aber es ist doch zumindest gewöhnungsbedürftig und wenn man nicht aufpasst etwas Fehlerträchtig im Bezug auf Zeiger und Referenzen. Da Objekte standardmäßig kopiert werden und man somit gezwungen ist Zeiger und Referenzen zu benutzen (oder wieder auf Performance verzichten), empfinde ich es als unangenehm.
Aber es gibt genug Leute die C++ für bequemer halten, einfach auch weil Sie es gewohnt sind damit umzugehen.

Ohne scheiss Drake du darfst nicht ales Glauben was OOP Fanatiker sagen.
Auch funktional kann man wartbaren Code schreiben.

Nunja, ich hab damit angefangen mein Spiel in C# zu schreiben, da es typensicher ist. Rennt auch mit Mono unter Linux, also bin nicht auf Windoof angewiesen.
Als Templates verwende ich eine eigene Klasse die mir ein XmlDocument generiert, welches dann mit einem XSLT Stylesheet am Serve rnoch geparst wird und gebe dem User dann HTML zurück.

Naja also ich glaube, wenn man XML erzeugt und das durch nen Parser+XSLT schickt um das eigentliche HTML zu erzeugen braucht man sich eigentlich keinen Kopf mehr zu machen ob der Generator in C# oder PHP geschrieben ist.
Für Gameplay ist es natürlich ne andere Sache, da da durchaus komplexere Aufgaben lauern können.

Mein System ist ziemlich dem von n26 gleich:
class.Template.php:

/**
* PHP-Version: 5.1
* Copyright (c) 2007 Moritz Wilfer
* Author: Moritz Wilfer
* Project: mooCMS
* File-Description: the small template class
**/
defined('accessFile') or die('File cannot be called directly');
require_once("exception/exception.Template.php");
class Template {
/**
* @templatePath string
*/
protected $templatePath = null;
/**
* constructor
*/
function __construct(iDatabase $Database) {
try {
$Database->query('SELECT templatePath
FROM #__templates
WHERE
templateIsActiv = 1
ORDER BY rand()
LIMIT 0,1');
} catch(EDatabase $e) {
showException($e);
exit;
}
while($row = $Database->fetchSingleRow())
$this->templatePath = "template/".$row->templatePath;
}
/**
* the parser function
*/
final public function parseTemplate($templateName, Parameter $Parameter) {
/**
* include the template
* if the file exists
*/
if(file_exists($this->templatePath."/".$templateName.".php")) {
/**
* start catching the output in a buffer
*/
ob_start();
require($this->templatePath."/".$templateName.".php");
$content = ob_get_contents();
ob_end_clean();
/**
* finally return the buffer
*/
return $content;
} else
throw new ETemplate($this->templatePath."/".$templateName.".php");
}
final public function showTemplate($templateName, Parameter $Parameter) {
echo $this->parseTemplate($templateName, $Parameter);
}
/**
* returns the templatePath
*/
public function getPath() {
return $this->templatePath;
}
}
?>
und zur Veranschaulichung ein Template:

get('ComponentHtml'); ?>

Bei einem anderen Projekt hingegen erstelle ich via PHP und Savant2 einen XML-String der dann mittels PHP-XSLT in valides XHTML 1.0 übersetzt wird.
Gruß
Moo

Mal ne ganz erst gemeinte Frage: Bringt das irgendwelche Vorteile, den Umweg über XML zu gehen?
Ich weiss, die halbe Welt bekommt von XML, XSLT, SOAP usw. feuchte Träume. Aber wenn die Zielausgabe XHTML 1.0 ist und ich nicht auch noch X andere Formate erzeugen will, wozu dann XML dazwischen?

Die Idee war mal, auch andere Formate anzubieten. (Evtl. Clientprogrammierung)
Desweiteren konnte damals, als ich das Projekt begonnen habe, noch nicht jeder Browser XSLT, deshalb nutzte / nutze ich noch die PHP-XSLT.
Ein weiterer Vorteil liegt auch darin, dass man schnell Tags anpassen kann. So kann ich z.B. festlegen, dass der Tag in übersetzt wird, und nicht mehr in .
Gruß
Moo

Das klingt ehrlich gesagt nach drei nicht validen Gründen:
1. alternatives Format: You Ain't Gonna Need It-Prinzip verletzt
2. Client-XSLT: Die Browser haben Schwierigkeiten, HTML ordentlich darzustellen. Da würde ich nicht mal an XSLT auf dem Client denken.
3. Tags ersetzen: Search'n'Replace und CSS lösen das Problem nicht?

Schließe mich Corthbrandt an.
Bin zwar absoluter Xml-Freak, aber bevor ich eine künstliche Zwischenebene baue, baue ich mir lieber verschiedene Viewer, die auf unterschiedliche Art und Weise unterschiedliche Ausgaben produzieren.
Und effektiv gesehen: Welches Anzeigeformat gibt es neben Xhtml?
WML ist tot, Html stinkt, PDF ist nicht dynamisch, XPS ebenso, Flash-Applets aus Xml... Viel Spaß, etc.
Wenn ich ein Clientprogramm schreiben möchte, dann greife ich direkt über WebServices auf die Datenschnittstelle zu...

Naja, ich geh den umweg über XSLT, da ich dann verschieden Layouts mit verschieden Stylsheets generieren kann. D.h. layout sachen die mit CSS nicht möglich sind, wie z.b das eine Desing arbeitet mit Tabellen, das andere mi Divs

* Eigentliche Ausgabe ist kleiner als XHTML, da reine Daten (4 Schichtenmodell)
* Ausgabe vom Programm ist wirklich komplett unabhängig vom Layout
* kein Templatesystem a la smarty notwendig, da XSLT (meiner Meinung nach) alles notwendige mitliefert
* Layoutänderungen geschehen am Template
* mit ein bisschen Gefühl fast unbegrenzte Erweiterungen möglich, man muss nur XML Kenntnisse haben
* alternative Layouts, alternative Ausgaben: DatenXMLs, Widgets/Gadgets, theoretisch clientsoftware (und wenn heute wer sagt, es ist alles tot: morgen kommt xml-wunderland 2.0 für windows.. und jeder darf ein neues xml-frontend bauen?)
Wegen alternativer Layouts: Zwar sollte man sich auf CSS konzentrieren, aber es gibt immer Situationen, wo es einfach am HTML-Struktur-Code liegt. Eine Webseite für Typ Handheld/PDA benötigt eben nicht so viel HTML-Kram wie für den Computer, CSS hin, CSS her.
Beispielsweise habe ich mal aus einer internen XML-Speicherung (für Datenbank wurden die Daten zu selten/gar nicht gelesen und waren zu komplex) zwei XSL gehabt: Das eine zum Einbinden und normalen Anzeigen, das zweite für eine Anzeige zum Runterladen. Was muss der Benutzer die interne Struktur wissen, wo Daten drin sind, die ihn nichts angehe. Und bevor ich das ganze Dokument rumparse, erledigt sich sowas mit etwas Waldwissenschaft (Bäume, XML, you get it?) halb automatisch.

Ok, vielleicht bin ich da einfach versaut, weil wir ja so ziemlich alles client-seitig in JS erzeugen und keine wirklichen Pages haben.

Original von COrthbandt
Ok, vielleicht bin ich da einfach versaut, weil wir ja so ziemlich alles client-seitig in JS erzeugen und keine wirklichen Pages haben.

Damit setzt du dann aber auch auf JS - wer das nicht hat/will, guckt in die Röhre. Wäre im Übrigen doch auch eine Möglichkeit für XSL: Template 1 für JS, Template 2 statisch ohne. Quasi ein "Fallback". Vielleicht mit weniger komfortablen Funktionen, aber zumindestens steuerbar.

ich kann mich da nicht ganz entscheiden....
ich habe mich für eine mischung des ganzen entschieden....
- die standard xhtml vorlage (grundgerüst, div's, header etc...) ist ne php datei, von der aus alles includiert wird....
- der rest des html wird in klassen generiert

a) und ein bisschen b)
... den wer a) sagt muss auch b) sagen.

Original von Amun Ra
Ich bastel immer noch allein und mag Smarty und co nicht.
Deshalb schreib ich die Ausgaben
und die Präsentationslogik direkt mit PHP ins Template.
Beispiel:
index.php

$array = ... ;
require 'index.tpl.php';
?>
index.tpl.php

Das ganze mag einem Entwickler der in einem Team arbeitet ein Dorn im Auge sein,
aber ich fahre ganz gut damit.
Und in Sachen Performance ist das nicht zu toppen ( mit PHP ).

kann ich nur alles bestätigen
darum nannte es sich ja auch mal phtml oder so ^^

Bei mir ist es ein Templatesystem.
Ich bin momentan dabei es massiv zu erweitern. So langsam entwickelt sich da eine kleine Scriptsprache draus.

Zum Thema XSLT: Auch wenn das gar nicht so lahm ist, wie ich hörte, wird die meiste Zeit zum Laden der Templates benötigt, da dürfte der xsltcache interessant werden.

Hört sich sehr interessant an. Hat aber einen kleinen Nachteil:
Jeder PHP Thread hat seinen eigenen Cache.(Nicht so schlimm, wenn die XSL Dateien nicht mehrere MB brauen )
Ausserdem wurde seit 3 Monaten nichts mehr gemacht.
Ach ja, Unter Windows nicht Funktionsfähig(nebensächlich)

Eine eigene kleine - aber flinke - Templateklasse.
Imho die beste Wahl wenn es um Übersichtlichkeit und erweiterbaren Code geht. - Es nervt nichts mehr als wenn man sich beim Programmieren noch stundenlang durch HTML Code lesen muss ...

Noch via echo aber sollte sich auch bald ändern.
Lg
Tom

ich bastel gerade ein bisschen weil man immerwieder Leute hört die sagen dass das entwickeln von Desktop anwendungen ja soviel schöner ist. also arbeite ich an einem objektorientierten ansatz der das problem erstmal stark abstrahiert.
das ganze sieht im ansatz etwa so aus: pastie.caboo.se/116917
mit eigenen componenten(klassen) und etwas vererbung kann man dann auch komplett auf html-bezug verzichten
die implementation für statisches html war schnell geschrieben. zurzeit sitze ich an dhtml unterstützung mit eventhandlern und was so dazugehört.
/edit: das ist übrigends ruby für ungläubige die das nicht selbst sehen

Wo ist der Vorteil, wenn der Output kürzer als der Input ist?

Verstehe ich ehrlich gesagt nicht: Warum nicht gleich selber XML einbauen? Ob man das XML nun jetzt nachher als HTML oder irgendwas "rendert", ist ja der Ausgabe überlassen. Zudem verstehe ich nicht, was in deinem Code da überhaupt passiert: Was haben bgcolor (gruselig) und die Styleangaben im HTML zu suchen? Und zusätzlich: Wieso sind Styleangaben die einzigen Angaben, die ein "div" beim konstruieren erhält?
Unter einem sauberen - und auch client- und ausgabeunabhängigen - Template verstehe ich die komplette Trennung von Layout, Design und Funktionalitäten wie Javascript (und dazu gehören natürlich auch JavaScript). Stichwort "EventHandler"....

ich hab grad einen ewiglangen beitrag ans forum verloren deshalb nochmal ganz ganz kurz:
Ihr habt das beispiel etwas falsch aufgefasst ...
das sollte eigentlich nur die Syntax beschreiben und war nur schnell dahin geschrieben
anstelle der html objekte treten aber in der Anwendung standard- und selbsterstellte Komponenten
(dann zb Window.new oder Navigation.new etc) die html objekte sind nur bausteine um solche komponenten zu bauen.
aussehen soll das am ende wie bei Desktop GUIs (zb ruby-gtk)

Wie sieht deine Lösung performance Technisch aus? Ist die Lösung schnell genug für den Betrieb unter Last (10'000 User ...)?

Also sieht das Ruby-Beispiel exakt wie ASP.Net aus. Ziel von ASP.Net und scheinbar auch von Ruby ist es eine konsistente Programmierung zwischen Desktop und Client zu ermöglichen.
Dort habe ich auch eine strikte Trennung zwischen Design und Ausgabe und kann einfach per new Calender() einen kompletten, blätterbaren Kalender erzeugen.
Für das Jungfrauenspiel nutzte ich die ASP.Net-Steuerelemente und ich muss sagen, dass diese perfekt für eine traditionelle Business-Anwendung sind, aber für ein Browserspiel etwas zu unflexibel sind.
Daher werde ich in meinem nächsten Projekt auf eine von mir entwickelte Template-Engine zurückgreifen.
BTW: Funktioniert Ruby on Rails auch während der Streiks?

Original von Chriss
Wie sieht deine Lösung performance Technisch aus? Ist die Lösung schnell genug für den Betrieb unter Last (10'000 User ...)?

Performance auf server seite sollte kein problem sein, da Das resultierende dhtml ja gecached werden kann und das script nur neu geladen werden muss wenn der quelltext geändert wird.

Für das Jungfrauenspiel nutzte ich die ASP.Net-Steuerelemente und ich muss sagen, dass diese perfekt für eine traditionelle Business-Anwendung sind, aber für ein Browserspiel etwas zu unflexibel sind.

unflexibel? kann man bei ASP.Net keine eigenen Steuerelemente erstellen beziehungsweise per vererbung oder ähnlichem Allgemeine komponenten anpassen?
Das man eine Seite meist nicht nur aus Standardkomponenten sollte ja klar sein

unflexibel? kann man bei ASP.Net keine eigenen Steuerelemente erstellen beziehungsweise per vererbung oder ähnlichem Allgemeine komponenten anpassen?
Das man eine Seite meist nicht nur aus Standardkomponenten sollte ja klar sein

Dies ist zwar möglich, nur besteht ein Browsergame selten aus vielen gleichen Steuerelementen, sondern am liebsten sehr individuell. Die Wiederverwendbarkeit ist gewissermaßen eingeschränkt.
Konkret nutze ich zum Beispiel eine Erweiterung der einfachen TextBox zur Eingabe von Spielernamen bei Nachrichten, Angriffen, etc. Es wird dort per Ajax überprüft ob der Spielername existiert und bei Bedarf werden Vorschläge im Stile von Google Suggest eingeblendet. Statt schreibe ich nur noch
Aber insgesamt hat mich dieses Modell konkret für Browserspiele nicht 100% überzeugt.

ASP.Net...
Beruflich (Firma) gerne. Die Objekte kann ich sehr gut in unseren Seiten verwenden.
Privat (Browsergame) kommt mir das nicht rein. Ich habe mich einige Tage damit beschäftigt und so viele eigene Klassen von bestehenden abgeleitet, daß ich beschlossen habe gleich alles selbst zu machen.
Das was übrig blieb, waren nur Grundlegende Basisobjekte. Und die baue ich dann halt selbst nach. Und zwar nur mit dem, was ich benötige.
Oder um es mit Worten eines Freundes auszudrücken... "ASP.Net stinkt".

so ich weiß der Thread ist schon alt, aber trotzdem will ich mal meinen Senf dazu geben
Ich bin mit den Asp.Net Controls bisher sehr gut gefahren...
Gebäude/Forschung/... -Listen werden meist mit einem datengebundenen Repeater erzeugt, ist nicht sehr "wiederverwendungsfreudig", aber diese Art von Listen brauche ich auch nur einmal! Und ich hab eigentlich immernoch ne relativ strenge Trennung von Logik und Anzeige.
Dann hab ich noch eigene Steuerelemte um z.B immer wiederkehrende Dinge anzuzeigen (Usernamen mit Verlinkung zum Profil, Planeten mit Verlinkung zur Karte usw). Das finde ich sehr schön, einfach die "User"-Klasse dem Control zuweisen und es wird angezeigt!
Ich find man kann also auch mit den asp.net controlls sehr gut in einen BG auskommen

Ich lasse mich aber auch gerne von euch überzeugen, dass es was besseres gibt (bisher wurde nur gesagt, dass sie "unflexibel" sind... ich finde sie sind min. genauso flexibel wie das dahinterstehende html, aber einfacher zuverwenden)

Bei mir ebenfalls b). Es hat bei mir ein sanfter Uebergang von a) nach b) stattgefunden. Derzeit bin ich bei einer eigenen Template-Engine mit View-Helpern angekommen. Von Smarty und Co. lasse ich lieber die Finger, da dies meistens Feature-Monster sind. Meine Engine ist da angepasst und wird auch staendig neu angepasst.
Hier mal ein Beispiel aus meiner freien Software.