Sie befinden sich hier: start » de » code_conventions

Code Konventionen (PLUGINS)

TODO: review

Tags

Man glaubt es kaum, aber man findet immer noch Templates und Plugins mit gross geschriebenen tags wie <BR>.

So etwas validiert nicht unter Xhtml, es ist auch unmodern und heute nicht mehr üblich. Vor Jahren hat man das so gemacht, um die tags im Quelltext besser zu erkennen. Heute gibt es moderne Editoren mit Syntax-Highlighting für alle gängigen Markup- und Programmiersprachen.

Entfernt also als erstes alle grossgeschriebenen tags aus den Quelltexten Eurer Templates und aller php-Dateien.

⇑ nach oben

Die Funktion tag

Diese Funktion ermöglicht es, CMSimple alle solo-tags wie <br>, <hr>, <img…> usw. je nach Einstellung von „xhtml_endtags:“ mit oder ohne end-tag ausgeben zu lassen.

Wir alle wissen, dass Xhtml mehr ist als „html mit end-tags“, aber mit der Ausgabe von solo-tags mit oder ohne end-tag ist es meistens schon getan.

tag() ist eine CMSimple-interne php-Funktion und wird wie folgt umgesetzt:

<?php echo tag('br');?>
 
ergibt: <br> oder <br />
 
<?php echo tag('hr');?>
 
ergibt: <hr> oder <hr />
 
<?php echo tag('img src="..." alt="..."');?>
 
ergibt:  <img src="..." alt="..."> oder <img src="..." alt="..." />

… je nach Einstellung von „xhtml_endtags:“

Bei komplizierteren tags wie <img…> muss man manchmal recht sorgfältig mit der php-Syntax sein, vor allem, wenn im tag wieder mit php-Variablen referenziert wird. Aber daran gewöhnt man sich schnell.

⇑ nach oben

Oft ist ein „&“ in dynamisch erzeugten Links eine Ursache für Fehlermeldungen bei der Validierung. Sonderzeichen in URLs müssen maskiert werden, das „&“ also als &amp; im Link stehen.

Das war auch die Ursache dafür, dass in CMSimple der printlink nicht validierte. Abhilfe schafft hier die Behandllung mit str_replace.

Hier als Beispiel der printlink in der cms.php:

else if(sv('QUERY_STRING') != '')$t = str_replace('&','&amp;',sv('QUERY_STRING')).$t;
 
return '<a href="'.$sn.'?'.$t.'">'.$tx['menu']['print'].'</a>';

In der 1. Codezeile wird die Variable $t aus dem QUERY_STRING erzeugt. Dieser QUERY_STRING enthält ein „&“.

In der 2. Codezeile wird die Variable $t in einem Link verwendet. Dadurch wird das „&“ aus dem QUERY_STRING im Link unmaskiert ausgegeben, wenn ich den QUERY_STRING nicht mit

str_replace('&','&amp;',sv('QUERY_STRING'))

behandle, und das gibt eine schöne Fehlermeldung unter Xhtml.

⇑ nach oben

scripts und CDATA

Oft ist im Template oder im Plugin javascript zu finden. Hier muss man dafür sorgen, dass das javascript nicht mit validiert wird.

Das kann ich auskommentieren, aber da protestieren sofort die Semantiker: „Was nicht validiert versteck' ich einfach, das kann doch nicht die Lösung sein …“.

Der moderne Weg, dem Validator mitzuteilen, dass es sich hier nicht um (X)html handelt und das javascript nicht mit zu validieren ist, ist [CDATA].

<script type="text/javascript">
/* <![CDATA[ */
 
das script
 
/* ]]> */
</script>

Die Kommentarzeichen verstecken nun wiederum das [CDATA] vor älteren Browsern, die das sonst anzeigen würden.

Der Validator weiss nun, dass es sich bei der so gekennzeichneten Passage nicht um (X)html handelt und dieser Abschnitt nicht mit zu validieren ist. [CDATA] steht nämlich für „character data“.

⇑ nach oben

2 Versionen

Wenn Du ein Xhtml-valides Plugin oder Template hast, ist die Umwandlung in ein html-valides Plugin oder Template eigentlich ein Kinderspiel.

Einfach durch alle php-Dateien „suchen & ersetzen“ laufen lassen. Suchen nach „ />“ und ersetzen durch „>“, und schon hast Du eine html-Version.

Dann einfach die Xhtml-Version mit „X“ am Ende kennzeichnen, die html-Version mit „H“, und schon entspricht Dein Plugin unseren Qualitäts-Kriterien.

Ups, bei einem Template muss natürlich noch die DTD ausgetauscht werden …

⇐ zurück ⇑ nach oben

Code Konventionen (TEMPLATES)

Doctype Declaration

Die erste Massnahme besteht darin, die Doctype Definition (DTD) dynamisch per php je nach Einstellung von „xhtml_endtags:“ einzubinden:

<?php
if ($cf['xhtml']['endtags'] == 'true') {
echo '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">'."\n".
'<html xmlns="http://www.w3.org/1999/xhtml">'."\n";
} else {
echo '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">'."\n".'<html>'."\n";}
?>

Weiter geht's mit:

<head>
...

Das <html> ist bereits mit eingebunden, da es bei Xhtml weitere Informationen enthält und somit auch je nach html oder Xhtml unterschiedlich gesetzt werden muss.

Wenn Du in Deinem Template solo-tags verwendest, musst Du natürlich auch alle solo-tags per php mit tag(' ') einbinden, so wie unter die Funktion tag beschrieben.

⇐ zurück

Die Zukunft mit html 5

Im Prinzip validieren alle in html 4.01 strict und Xhtml 1.0 strict geschriebenen Dokumente auch unter html 5, das lässt nämlich sowohl end-tags als auch die Syntax ohne end-tags zu.

Die unter den transitional-Varianten von html 4.01 und Xhtml 1.0 möglichen html-Formatierungen wie z. B. border=0 werden unter html 5 nicht mehr erlaubt sein. Es geht also konsequent in die Richtung „Trennung von Inhalt und Gestaltung“. Eine transitional-Variante ist in html 5 nicht vorgesehen.

Deshalb empfehlen wir allen Entwicklern von Templates und Plugins, diese nach den strengen Regeln der strict-Varianten von html 4.01 und Xhtml 1.0 zu entwickeln.

Dann wird es auch kaum Probleme bei der Umstellung auf html 5 geben. Einfach den genial einfachen Doctype von html 5 setzen:

<!DOCTYPE html>

und fertig ;-)

Aber es wird noch Jahre dauern, bis das offiziell ist, bis die Browser es zulassen, den vollen Umfang von html 5 zu nutzen und vor allem bis die Editoren html 5-konformen content schreiben. Bis dahin wird man mit CMS auch weiterhin die transitional-Varianten von html und Xhtml benutzen müssen.

Unsere Bemühungen um (X)html sind also nicht umsonst.

Auch der Name CMSimple_XH wird weiterhin seine Berechtigung haben, da html 5 eigentlich die Zusammenführung von html 4.01 strict und Xhtml 1.0 strict ist.

Der Anwender wird auch weiterhin die Möglichkeit haben, Inhalte mit oder ohne end-tags zu erzeugen, nur wird das für die Validierung unter html 5 keine Rolle mehr spielen.

Mit end-tags ist es halt XML-kompatibel, und wer weiss schon, was in ein paar Jahren wieder modern ist …

⇐ zurück ⇑ nach oben

 
Sie befinden sich hier: start » de » code_conventions
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: GNU Free Documentation License 1.3
Valid XHTML 1.0 Valid CSS Driven by DokuWiki