Schöne quelltexte
davidsen
- php
beim ganzen kombinieren von php und html: wie schafft man es eigentlich, dass die quelltexte bei der ansicht über den browser auch noch schön aussehen?
Grüße,
beim ganzen kombinieren von php und html: wie schafft man es eigentlich, dass die quelltexte bei der ansicht über den browser auch noch schön aussehen?
wenn du bei "schön"->"eingerückt" oder zumindest "zeilenweise" meinst-> mit viel aufwand. du kannst höchstens statt echo einen umweg nehmen um imme rinen zeilenumbruch (newline) zu haben, sons tnicht viel AFAIK
MFG
bleicher
[latex]Mae govannen![/latex]
Grüße,
beim ganzen kombinieren von php und html: wie schafft man es eigentlich, dass die quelltexte bei der ansicht über den browser auch noch schön aussehen?
wenn du bei "schön"->"eingerückt" oder zumindest "zeilenweise" meinst-> mit viel aufwand. du kannst höchstens statt echo einen umweg nehmen um imme rinen zeilenumbruch (newline) zu haben, sons tnicht viel AFAIK
Wenn man Bereiche hat, die statisch sind oder größtenteils immer gleich bleiben, kann man den PHP-Bereich verlassen, das HTML wie bei einer reinen HTML-Seite schreiben (mit Einrückungen und Zeilenumbrüchen) und nur die Bereiche, in denen sich etwas ändert, wieder als PHP-Bereich definieren, dann hat man das schon mal so wie gewünscht.
Ansonsten mit Zeichenketten in Heredoc-Schreibweise arbeiten, auch hier bleiben Einrückungen und Zeilenumbrüche erhalten.
Für den Rest tut es bei mir eine kleine Klasse, die intern die Anzahl Einrückungen behält und bei jedem Aufruf diese Anzahl Einrückungen ausgibt, solange der Wert nicht geändert wurde.
Das sieht bei mir so aus (sehr stark vereinfachte Darstellung):
//Indent::set(' '); # Das hier wären zwei mögliche übliche Aufrufe
//Indent::set("\t");
Indent::set('XY'); # Zur Verdeutlichung nehme ich aber die Zeichenkette XY als Einrückung:
Indent::iprint('Ein Text'); # Zähler ist noch 0, weil die change()-Methode noch nicht aufgerufen wurde
//Ein Text <-- Ausgabe
Indent::change(2);
Indent::iprint('Ein Text'); # Zähler ist 0 + 2 = 2, also 2x Einrückung
//XYXYEin Text
Indent::iprint('Ein Text'); # Zähler ist immer noch 2 ....
//XYXYEin Text
Indent::change(-1);
Indent::iprint('Ein Text'); # Nun ist der Zähler 2 + (-1) = 1, also 1x Einrückung
//XYEin Text
Indent::change(1);
Indent::iprint('Ein Text'); # Zähler wird um 1 erhöht, also 1 + 1 = 2x Einrückung
//XYXYEin Text
Kann man als Anregung nehmen oder auch lassen :D
Cü,
Kai
Grüße,
ich dachte explizit augerufene methoden hätten kein zugriff auf klasseigenschaften bzw. $this wie speicherst du die einrückungstufe?
MFG
bleicher
[latex]Mae govannen![/latex]
Grüße,
ich dachte explizit augerufene methoden hätten kein zugriff auf klasseigenschaften bzw. $this wie speicherst du die einrückungstufe?
ohne $this natürlich :D
Ich habe zwar extrem wenig Ahnung von OOP und dieser ganzen Klassen-Thematik (und komme irgendwie nie dazu, dies zu ändern), aber kurz zusammengestümpert:
class A {
private static $ic = 0;
public static function A1($a1) {
self::$ic = $a1;
}
public static function A2() {
echo self::$ic;
}
}
A::A2(); #0
A::A1(3);
A::A2(); #3
A::A2(); #3
A::A1(7);
A::A2(); #7
Cü,
Kai
beim ganzen kombinieren von php und html: wie schafft man es eigentlich, dass die quelltexte bei der ansicht über den browser auch noch schön aussehen?
Du kannst Strings in PHP auch über mehrere Zeilen angeben
$sql = "
SELECT Feld1, Feld2, ..., FeldN
FROM tabelle
";
echo '
<body>
<h1>Titel</h1>
<div id="deineid">
<p>Absatz</p>
</div>
</body>
';
Nur wird halt diese Möglichkeit so gut wie nie genutzt.
[latex]Mae govannen![/latex]
Du kannst Strings in PHP auch über mehrere Zeilen angeben
[...]
echo '
<body>
<h1>Titel</h1>
<div id="deineid">
<p>Absatz</p>
</div>
</body>
';
~~~php
// PHP-Code
// PHP-Code
// PHP-Code
?>
<body>
<h1>Titel</h1>
<div id="deineid">
<p>Absatz</p>
</div>
</body>
<?PHP
// PHP-Code
// PHP-Code
ist viel einfacher, und man kann -je nach Art der Ausgabe- auch noch diverse Escapes sparen.
Cü,
Kai
Lieber DiBo33,
Nur wird halt diese Möglichkeit so gut wie nie genutzt.
ach ja? Also ich bemühe mich, bei meinen Seiten "schöne" Quelltexte zu erzeugen. Kannst ja mal bei meinem Großprojekt hineinschauen, inwieweit mir das auch gelingt: Peutinger-Gymnasium
Liebe Grüße,
Felix Riesterer.
Hi,
Nur wird halt diese Möglichkeit so gut wie nie genutzt.
ach ja? Also ich bemühe mich, bei meinen Seiten "schöne" Quelltexte zu erzeugen. Kannst ja mal bei meinem Großprojekt hineinschauen, inwieweit mir das auch gelingt: Peutinger-Gymnasium
Welche Vorteile hat ein Programmierer überhaupt davon? Wenn man statische HTML-Seiten schreibt ist es für die eigene Überischt besser, wenn man Zeilen entsprechend einrückt. Aber wenn man dynamische Seiten erzeugt reicht es doch, wenn es im Quellcode (z.B. PHP oder Perl) übersichtlich angeordnet ist. Wie dann der erzeugte Quellcode (optisch) aussieht ist doch eigentlich egal?
Wenn man den HTML-Output analysieren will kann man auch ein Tool wie Firebug benutzen, das das ganze dann wieder übersichtlich darstellt.
Seht ihr das anders?
mfG,
steckl
Hi!
Welche Vorteile hat ein Programmierer überhaupt davon?
Kaum einen, üblicherweise. Wenn man seine Ausgabe analysieren will, ist es vorteilhaft, wenn diese gut lesbar ist. Ansonsten ist der Quelltext normalerwiese für den Browser bestimmt, der sich überhaupt nicht um die Formatierung kümmert. Will man sich selbst allerdings auch mit Hilfe des Quelltextes präsentieren, so tut man gut daran, ihn ordentlich schreiben zu lassen.
Alles hat seine Vor- und Nachteile. Hat man beispielsweise eine Code-Komponente, die ein fertiges Stück HTML erzeugt - zum Beispiel ein Formulargenerator oder ein Datagrid (Ausgabe von tabellarischen Daten) - so muss man dieser noch generell die aktuelle Einrückungsebene übergeben und Code dazuschreiben, der diese immer in die Ausgabe einfügt. Damit wird der Code der Komponente nicht einfacher. Die Frage ist, ob sich der zusätzliche Code inklusive Wartung und auch der damit verbundene Rechenaufwand rentiert.
Wenn man statische HTML-Seiten schreibt ist es für die eigene Überischt besser, wenn man Zeilen entsprechend einrückt. Aber wenn man dynamische Seiten erzeugt reicht es doch, wenn es im Quellcode (z.B. PHP oder Perl) übersichtlich angeordnet ist. Wie dann der erzeugte Quellcode (optisch) aussieht ist doch eigentlich egal?
Die Frage ist, wo hat man den größeren Nachteil. Schreibe ich den Text so, dass er in der Ausgabe ordentlich aussieht, sieht es vielleicht bei mir im Code schrecklich aus, weil die Einrückungsebnen von PHP nicht mit denen des zukünftigen HTML übereinstimmen.
Allerdings kann man mit dem EVA-Prinzip schon eine Menge Sortierung und Ordnung in seinen Code bringen. Dabei gestaltet man seinen Ablauf so, dass die Verarbeitung nur reine Daten erzeugt und kein HTML direkt ausgibt. Dafür ist dann der Ausgabeteil zuständig. So kann man sich die Probleme mit der Vermischung der verschiedenen Ebenen (PHP und HTML) klein halten.
if (...) {
if (...) {
if (...) {
if (...) {
echo " <table>\n";
foreach (...) {
echo " <tr>
<td>foo</td>
<td>bar</td>
</tr>\n";
}
echo " </table>\n";
}
}
}
}
So sieht das vielleicht in der Ausgabe ordentlich aus, aber hier nicht. Es wird auch nicht besser, mit der Heredoc-Syntax:
if (...) {
if (...) {
if (...) {
if (...) {
echo " <table>\n";
foreach (...) {
echo <<<LINE
<tr>
<td>foo</td>
<td>bar</td>
</tr>
LINE;
}
echo " </table>\n";
}
}
}
}
Wie wär's mit EVA?
$table = array();
if (...) {
if (...) {
if (...) {
if (...) {
foreach (...) {
$table[] = array('foo', 'bar');
}
}
}
}
}
?>
[...]
<table>
<?php foreach ($table as $row): ?>
<tr>
<td><?php h($row[0]) ?></td>
<td><?php h($row[1]) ?></td>
</tr>
<?php endforeach; ?>
</table>
h() ist in dem Beispiel eine Abkürzung und sieht in Gänze mindestens so aus:
function h($s) {
echo htmlspecialchars($s);
}
Wenn man den HTML-Output analysieren will kann man auch ein Tool wie Firebug benutzen, das das ganze dann wieder übersichtlich darstellt.
Jein. Damit bekommt man ein interpretiertes Ergebnis, und Browser sind bekanntlich fehlertolerant. Mit dieser Anzeige findet man nicht alle Probleme, die ein Validator ankreiden würde.
Lo!
Welche Vorteile hat ein Programmierer überhaupt davon?
Kaum einen, üblicherweise.
Denn häufig ist die Konstruktion von HTML/XHTML/HTML5/XHTML5 so geartet, dass HTML gar niccht mehr im Code augenscheinlich ist.
Hier eine sub aus einem Perl Modul, das zugleich Webform-Server ist.
sub __webform {
caller eq __PACKAGE__ or die "pivate method call";
my $self = shift;
my $new = shift || 0;
my $ht = '<form' . attr(action=>'', method=>'post').'>'.NL;
my $gid = 0;
$new and $user = sha1_hex( time() . $self->{config}{formid} );
print STDERR ' 2:', $user;
foreach my $g ( sort keys %{ $self->{layout} } ){
$ht .= '<fieldset id="sfm' . ++$gid . '">' . NL
. ' <legend>' . htmlchars( $self->{layout}{$g}{title} ) . '</legend>' . NL
. ' <ul>' . NL;
my $fid = 0;
foreach my $f ( @{ $self->{layout}{$g}{fields} } ){
$ht .= ' <li id="sfm' . $gid . ++$fid . '">';
if( $self->{fields}{$f}{type} =~ /text|textarea|select/ ){
$ht .= '<label'. attr('for', $f) . '>'
. htmlchars( $self->{fields}{$f}{title} )
. ( $self->{fields}{$f}{required}
? '<sup>*</sup>' : '')
. '</label>';
}
if( $self->{fields}{$f}{type} eq "text" ){
$ht .= '<input'
. attr( type=>'text', id=>$f, name=>$f, value=>$self->{fields}{$f}{value} );
$isht5 and $self->{fields}{$f}{required}
and $ht .= attr( required=>undef );
$ht .= $EM;
}
elsif( $self->{fields}{$f}{type} eq "textarea" ){
$ht .= '<textarea' . attr( id=> $f, name=>$f, cols=>40, rows=>10);
$isht5 and $self->{fields}{$f}{required}
and $ht .= attr( required=>undef );
$ht .= '>' . htmlchars( $self->{fields}{$f}{value} ) . '</textarea>';
}
elsif( $self->{fields}{$f}{type} eq "select" ){
$ht .= '<select' . attr( id=> $f, name=>$f );
$isht5 and $self->{fields}{$f}{required}
and $ht .= attr( required=>undef );
$ht .= '>'.NL;
foreach my $o ( keys %{ $self->{fields}{$f}{value} } ){
$ht .= ' <option' . attr( value=>$o );
$o eq $self->{fields}{$f}{selected} and
$ht .= attr( selected=>undef );
$ht .= '>'. htmlchars( $self->{fields}{$f}{value}{$o} )
. '</option>'.NL;
}
$ht .= ' </select>';
}
elsif( $self->{fields}{$f}{type} eq "check" ){
$self->{fields}{$f}{title}
and $ht .= '<p class=label>'.htmlchars($self->{fields}{$f}{ title} ).'</p>';
$ht .= NL.' <ul class=sfmcheck>';
foreach my $o ( keys %{ $self->{fields}{$f}{value} } ){
$ht .= '<li><label>'
. '<input' . attr( type=>'checkbox', name=>$f, value=>$o );
exists $self->{fields}{$f}{checked}{$o} and
$ht .= attr( checked=>undef );
$ht .= '>'. htmlchars( $self->{fields}{$f}{value}{$o} )
. '</label></li>';
}
$ht .= '</ul>'.NL.' ';
}
elsif( $self->{fields}{$f}{type} eq "submit" ){
$ht .= '<label class="hidden" for="'.$f.'">'.t('submitlabel').'</label><input'
. attr( type=>'submit', id=>$f, value=>$self->{fields}{$f}{title} )
. $EM . NL;
$ht .= ' <input'
. attr( type=>'hidden', name=>'formuser', value=> $user )
. $EM;
}
$ht .= '</li>'.NL;
}
$ht .= ' </ul>'. NL . '</fieldset>' . NL;
}
$ht .= '</form>'.NL;
if( $new ){
open(F, ">>", "sfm.log") or die( t("err sfm.log"). " $!" );
print F 'user=',time(),'-',$user, NL;
close(F);
}
return $ht;
}
Für das Formular wird der Versuch gemacht ihm eine lesbare Formatierung zu geben. Aber Verschwenderischer Whitespace ist nicht einmal angesagt, da damit gewisse CSS Formatierungsmöglichkeiten gestört werden.
HTML Templates sind hier fruchtlos.
mfg Beat
Hi,
Eine sehr ausfuehrliche Antwort.
Wie wär's mit EVA?
$table = array();
if (...) {
if (...) {
if (...) {
if (...) {
foreach (...) {
$table[] = array('foo', 'bar');
vielleicht koennte man auch gleich hier den Aufruf von h() einbauen. Dann kann man die Strings auch in Perl ohne [link:http://forum.de.selfhtml.org/archiv/2007/2/t147092/#m954548@title=Umwege] in einem Here-Doc block ausgeben lassen.
}
}
}
}
}
> ?>
> [...]
> ~~~html
<table>
> <?php foreach ($table as $row): ?>
> <tr>
> <td><?php h($row[0]) ?></td>
> <td><?php h($row[1]) ?></td>
> </tr>
> <?php endforeach; ?>
> </table>
Das ist wohl die beste Moeglichkeit Programm- und HTML-Code uebersichtlich zu halten.
Wenn man den HTML-Output analysieren will kann man auch ein Tool wie Firebug benutzen, das das ganze dann wieder übersichtlich darstellt.
Jein. Damit bekommt man ein interpretiertes Ergebnis, und Browser sind bekanntlich fehlertolerant. Mit dieser Anzeige findet man nicht alle Probleme, die ein Validator ankreiden würde.
Daran habe ich nicht gedacht, aber es gibt sicher andere Tools, die den HTML-Quelltext in seiner urspruenglichen Form uebersichtlich darstellen koennen.
Die Frage ist was schneller ist. Entweder gleich "schoenen" HTML-Code erzeugen, oder ein Tool verwenden, das den Code anschliessend formatiert.
mfG,
steckl
Hi!
Wie wär's mit EVA?
foreach (...) {
$table[] = array('foo', 'bar');vielleicht koennte man auch gleich hier den Aufruf von h() einbauen. Dann kann man die Strings auch in Perl ohne Umwege in einem Here-Doc block ausgeben lassen.
Dagegen! Das widerspricht einerseits dem EVA-Prinzip, weil h() eine ausgabe- und keine verarbeitungsrelevante Funktion ist. Im obigen Programmteil sollen nur Daten erzeugt werden, die unabhängig vom späteren Ausgabemedium sind.
<td><?php h($row[0]) ?></td>
Andererseits muss du dann hier im Ausgabeteil immer zwischen bereits behandelten und noch zu behandelnden Werten unterscheiden. Bei "alles sind Rohdaten" fällt diese fehlerträchtige Überlegung weg, weil eben ausnahmslos alles noch kontextgerecht zu behandeln ist.
Lo!
Hallo dedlfix,
h() ist in dem Beispiel eine Abkürzung und sieht in Gänze mindestens so aus:
function h($s) {
echo htmlspecialchars($s);
}
nutzt Du eine solche Kapselfunktion im Live-Betrieb? Ist der Overhead soweit vernachlässigbar, dass man ihn für rein optische Effekte im Quelltext in Kauf nehmen sollte?
Ich finde die Idee gut, da er gerade bei sinnvoller Nutzung von PHP (ist m.E. in sich schon ein Template-System, wenn man Verarbeitung und Ausgabe sauber trennt) die Übersichtlichkeit erhöht. Aber damit schaffe ich ja zu jeder Ausgabe einen zusätzlichen Funktionsaufruf. Lohnt das?
Gruß, Thoralf
Hi!
h() ist in dem Beispiel eine Abkürzung und sieht in Gänze mindestens so aus:
function h($s) {
echo htmlspecialchars($s);
}
> nutzt Du eine solche Kapselfunktion im Live-Betrieb? Ist der Overhead soweit vernachlässigbar, dass man ihn für rein optische Effekte im Quelltext in Kauf nehmen sollte?
Ja, schon weil der kurze Name deutlich weniger Platz als das ausgeschriebene "echo htmlspecialchars" einnimmt. Die PHP-Kurzform <?= um das echo zu sparen bringt auch noch nicht viel. In diesem Fall ist mir die Wartbarkeit wichtiger als das bisschen Performance, das das kostet. Allerdings:
"In echt" ist die noch etwas länger, weil noch [ein wenig mehr Funktionalität](/archiv/2008/9/t177348/#m1171971) drinsteckt.
> Aber damit schaffe ich ja zu jeder Ausgabe einen zusätzlichen Funktionsaufruf. Lohnt das?
Dazu musst du auch das "was kostet es?" ermitteln. Miss die Unterschiede mit einem Tool wie Apache Benchmark (ab) und setz das Ergebnis in Relation zu den für dein Projekt zu erwartenden Zugriffszahlen. Minimal die Performance zu erhöhen bring es kaum, wenn zu Hochlastzeiten deutlich mehr nachgefragt wird, als eingespart wurde.
Lo!
N'Abend,
"In echt" ist die noch etwas länger, weil noch ein wenig mehr Funktionalität drinsteckt.
Danke! Enthält einige Anregungen und scheint mir lasttechnisch kein wirklicher Faktor zu sein. Werd mir so etwas wohl auch angewöhnen!
Gruß, Thoralf
Lieber steckl,
"schöne" Quelltexte
Welche Vorteile hat ein Programmierer überhaupt davon?
in der Entwicklung sehe ich im Quelltext sehr viel schneller, wo etwas nicht so läuft, wie ich das beabsichtigt habe, eben weil er nicht so aussieht, wie er soll. Ohne "schöne Formatierung" tue ich mir da sehr schwer, das sofort zu erkennen. Da reicht mir dann das Syntaxhighlighting in der Quelltextansicht meines FF (manchmal) nicht.
Aber wenn man dynamische Seiten erzeugt reicht es doch, wenn es im Quellcode (z.B. PHP oder Perl) übersichtlich angeordnet ist. Wie dann der erzeugte Quellcode (optisch) aussieht ist doch eigentlich egal?
Nicht bei der Fehlersuche! Ich brauche z.B. beim Validieren einen übersichtlichen HTML-Code, wenn ich Fehler finden will.
Wenn man den HTML-Output analysieren will kann man auch ein Tool wie Firebug benutzen, das das ganze dann wieder übersichtlich darstellt.
Der Browser macht doch aus meiner Tagsoup ein Dokument und erzeugt das entsprechende DOM. Dass das DOM mit meiner Tagsoup nicht mehr unbedingt viel zu tun hat, solltest Du doch auch bestätigen können, oder?
Seht ihr das anders?
Ja.
Liebe Grüße,
Felix Riesterer.
Hallo!
Wie dann der erzeugte Quellcode (optisch) aussieht ist doch eigentlich egal?
Eigentlich ja. Ist halt eine Frage der Ästhetik. Diese kann "Perfektionisten" schon überproportional wichtig sein. Auch wenn sich wohl 99% der Benutzer überhaupt nicht für den Quellcode interessieren.
Seht ihr das anders?
Ja!
Viele Grüße
Thorsten
Lieber Michael,
Peutinger-Gymnasium
Aehm.. Großprojekt ??
für mich als interessierter Laie ist das ein Großprojekt. Dazu kommt, dass man nicht alles sieht, was dahinter steckt, denn im Hintergrund laufen ein paar Scripte, die für unsere internen Abläufe wesentlich sind, die man aber als regulärer Besucher der Website nicht sieht.
Liebe Grüße,
Felix Riesterer.
Liebe(r) davidsen,
benutze reine HTML-Dateien als Vorlagen und befülle bestimmte Bereiche darin mit Deinen geskripteten Inhalten. Damit kannst Du die Einrückungen im HTML-Code zumindest teilweise garantieren.
In Deinen Scripts müsstest Du Dich schon selbst um Einrückungen bemühen. Wie das geht, haben meine Vorposter bereits angeführt.
Liebe Grüße,
Felix Riesterer.
Das würde ich auch gerne wissen. find ich nicht so einfach!
Liebe Jasmina,
Das würde ich auch gerne wissen. find ich nicht so einfach!
ist das wieder so ein Content-Spam-Mist?
Liebe Grüße,
Felix Riesterer.
Hello Felix,
Das würde ich auch gerne wissen. find ich nicht so einfach!
ist das wieder so ein Content-Spam-Mist?
Klär mich bitte mal auf, was meinst Du mit "wieder"?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Lieber Tom,
was meinst Du mit "wieder"?
ach, zur Zeit posten Leute in meinem GB den üblichen SPAM (ist aber offensichtlich händisch eingetragen worden) und ebenso erlebe ich das in einem von mir mitbetreuten Forum. Daher das "[schon] wieder".
Liebe Grüße,
Felix Riesterer.
Hallo
was meinst Du mit "wieder"?
ach, zur Zeit posten Leute in meinem GB den üblichen SPAM (ist aber offensichtlich händisch eingetragen worden) und ebenso erlebe ich das in einem von mir mitbetreuten Forum. Daher das "[schon] wieder".
Ja, so kann man sagen.
Tschö, Auge
Hallo,
Das würde ich auch gerne wissen. find ich nicht so einfach!
ist das wieder so ein Content-Spam-Mist?
Ja, ist es.
Wen es interessiert: ich würde denic.de empfehlen und dann z.B.:
http://www.diplom.de/Bachelorarbeit-13094/Guerilla_Marketing.html
Grüße
Thomas
beim ganzen kombinieren von php und html: wie schafft man es eigentlich, dass die quelltexte bei der ansicht über den browser auch noch schön aussehen?
HTML muss nicht "schön" sein. Es muss sich zum Debugging eignen. Zeilenumbrüche sind hier wichtig,
Die Formatierung der Scriptquelle hat für mich Vorrang.
Schlüsselstellen im HTML gebe ich Randbündig aus.
Essentielle Blöcke durch zwei Newlines separiert.
Ansonsten ein Tab (in den meisten Viewern dann 8 Zeichen).
In Schleifen bei verschachtelten Listen verwende ich auch mal explizitere Einrückung.
Wer des öfteren mit display:inline-block arbeitet, ist bezüglich Whitespace zwischen Elementen sowieso eingeschränkt.
mfg Beat
Hallo davidsen,
beim ganzen kombinieren von php und html: wie schafft man es eigentlich, dass die quelltexte bei der ansicht über den browser auch noch schön aussehen?
z.B. indem man php und html komplett trennt - HTML-Template, in php einlesen, ausfüllen
Dann kannst das html stylen und den php-Code übersichtlich formatieren
Grüsse, armin
z.B. indem man php und html komplett trennt - HTML-Template, in php einlesen, ausfüllen
Leider hab ich bisher noch kein schönes Template-System bisher gesehen, und damit mein ich nicht mal unbedingt fertige Bausteine.
Ich arbeite selbst im Moment an einer Art Template-System weil mir die anderen nicht gefallen, habe ich bisher noch meine Probleme Platzhalter und Schleifen richtig ein zusetzten. So das es a) nicht in regulärem HTML/CSS/JS vorkommen kann und b) im Zweifelsfall valide ist.
So das es a) nicht in regulärem HTML/CSS/JS vorkommen kann und b) im Zweifelsfall valide ist.
Was sprich gegen HTML-Kommetare?
Die Template-Engine von TYPO3 verwendet z.B. welche in diesem Schema:
<!-- ###foo### -->
Inhalt der durch die Template-Engine ersetzt wird
<!-- ###foo### -->
alternativ kann man die Dinger auch noch kommenterien und verschachteln
<!-- ###foo### ab hier beginnt der subpart "foo" -->
Inhalt der durch die Template-Engine ersetzt wird, aber auch hier können wiede <!-- ###bar### -->weitere suparts<!-- ###bar --> vorkommen
<!-- ###foo### ende des subparts -->
Wenn das Template nun ohne Programmcode ausgeführt wird, stehen im Quelltext zwar kommentare, aber der Code ist nachwievor gültig.
Was sprich gegen HTML-Kommetare?
Muss ich drüber nachdenken.
"<!--### xxx ###-->" kann man natürlich per Regex sofort erfassen, es ist valide und kein Mensch schreib solche Kommentare.
Klingt eigendlich gut.