nicht angemeldet
Hi!
$arDocument['Title'] = toTag('h1, '', 'Tolle Seite');
$arDocument['Inhalt']= toTag('p', 'style="text-align:center"', 'Willkommen auf der tollen Seite!');
$arDocument['Menue']= toTag('a', 'href="/"', 'Startseite');
Wenn ich ein solche System aufsetzen wollte, würde ich hier einiges anders machen.
Die Reihenfolge der Parameter 2 und 3 sind ausgetauscht einfacher zu handhaben, denn Attribute sind im HTML-Start-Tag oftmals optional. Wenn man da also den Attribut-Parameter nach den Pflichtparametern (hier Elementname und Content) platziert und ihn mit einem Defaultwert im Funktionskopf als optional gestaltet, kann man sich den Leerstring in Fällen wie der ersten Zeile sparen.
Ansonsten ist das Prinzip der Attributhinzufügung einfach. Zu einfach für meinen Geschmack, denn eigentlich will man sich ja das Notieren von HTML sparen und konsequenterweise dann auch, die Notwendigkeit der korrekten Formulierung der Atttribute - inklusive der Berücksichtigung des Kontextwechsels beim Einfügen von Werten zuzüglich der von der PHP-Syntax geforderten Notationsweise von Anführungs- und Steuerzeichen.
Deshalb würde ich statt dem fertig ausformulierten Attribut ein Array übergeben, mit den Attributnamen als Key. Die Attributwerte sollten in Rohform übergeben werden, ansonsten ist an der Stelle nur die PHP-Syntax zu beachten. Die Funktion toTag() setzt selbständig aus dem Array den Attributstring zusammen - bei Beachtung des Kontextwechsels, also mit Anwendung von htmlspecialchars().
Unabhängig von der Frage ob CSS in style-Attributen sinnvoll ist oder nicht, müsste man für das style-Attribut konsequenterweise auch eine Trennung nach CSS-Eigenschaftsnamen und -Wert vornehmen. style bekommt im oben genannten Array eine Sonderbehandlung. Wenn (inkonsequenterweise) ein String übergeben wird, kommt der so in die Ausgabe, ein Array mit Eigenschaftennamen als Keys wird erst noch zusammengebaut.
Für den Inhalt (ex 3., neu 2. Paramter) kann neben reinem Text, der von der Funktion kontextgerecht zu behandeln wäre, auch HTML-Code notwendig sein, der nicht mehr behandelt werden darf (und andererseits dessen Inhalte bereits behandelt sein müssen). Um das zu unterschieden bedarf es eines Kriteriums. Der Datentyp ist beides Mal String, ist also ungeeignet. Ein weiterer Parameter $contentIsHtml wäre eine einfache Lösung, aber keine besonders hübsche. Hier kommt man dann langsam an den Punkt, an dem OOP sinnvoll wird, denn da kann man sich beliebig neue Typen durch Definieren von Klassen schaffen und auf die man Parameterwerte dann prüfen kann.
Zu guter Letzt würde ich neben der allgemeinen toTag()-Funktion noch spezialisierte Funktionen für die am meisten verwendeten Elemente schaffen, beispielsweise toPTag(), toATag(), toImgTag() und so weiter, bei denen man sich die Übergabe des Elementnamens spart, stattdessen aber oft verwendete Attribute als eigenständige Parameter vorsieht, damit man nicht immer selbst das Attribut-Array erstellen muss.
Und dabei (bei img) fällt mir ein, dass toTag() derzeit leere Elemente nicht berücksichtigt. Da würde sich anbieten, den Content-Parameter ebenfalls optional zu machen, ihn mit null als Defaultwert zu belegen und dieses null auswertend Elemente mit schließenden Tag zu erzeugen <img.../>. Für leere Elemente mit Start- und Endtag (<p></p>) fällt mir zwar grad kein Anwendungsfall ein, der nicht stattdessen mit CSS zu lösen ginge, aber hier müsste man dann explizit einen Leerstring übergeben. (Hmm, Platzhalter für Javascript-Spielereien wäre ein Fall.)
Lo!
Gunnar Bittersmann